Author |
Message
|
frankdurhine |
Posted: Tue May 09, 2006 7:21 am Post subject: mcauser - acl security: works difefrnt for persistent msgs? |
|
|
 Novice
Joined: 04 Oct 2005 Posts: 10
|
To secure an incoming sdr-rcvr channel-pair, I have configured the receiver with an mcauser in a group other than mqm and set the relevant authorities. Non persistent Messages are delivered properly when the group is allowed to "put" and "setall" into my testqueue "TEST.MCAUSER". I withdraw the acl rights and the messages were discarded.
But this does not work with non persistent messages: The channel is going to the retrying state then.
Does anyone know about particular settings I woluld have to give for the persistent messages?
Appreciate your ideas and help.
MQ is 5.3 onSolaris 10.
Code: |
channel mcauser is "mcacust" in group "mcacust". putaut is def.
$dmpmqaut -m QMGR1 -g mcacust
profile: TEST.MCAUSER
object type: queue
entity: mcacust
entity type: group
authority: put setall
- - - - - - - -
profile: DEAD.LETTER.QUEUE
object type: queue
entity: mcacust
entity type: group
authority: put setall
- - - - - - - -
profile: self
object type: qmgr
entity: mcacust
entity type: group
authority: inq connect altusr setall
- - - - - - - -
profile: @class
object type: queue
entity: mcacust
entity type: group
authority: none
- - - - - - - -
profile: @class
object type: qmgr
entity: mcacust
entity type: group
authority: none
- - - - - - - - |
|
|
Back to top |
|
 |
wschutz |
Posted: Tue May 09, 2006 7:30 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Its not really a security issue. If the channel has npmspeed=fast, an effect is that undeliverable non-persistent messages are discarded. Persistent messages are never discarded. Do you have dead letter queue defined on the receiving end? _________________ -wayne |
|
Back to top |
|
 |
frankdurhine |
Posted: Tue May 09, 2006 11:11 pm Post subject: |
|
|
 Novice
Joined: 04 Oct 2005 Posts: 10
|
thanks wayne. We have a dead letter queue (DEAD.LETTER.QUEUE) on the receiving end, and the mcauser is entitled to put on it.
I am afraid I did not put my question right, please reconsider: the point is not that npm are discarded and persistent messages not, but that I get access with non persistent messages, while persistent messages are still blocked by stopping the channel. |
|
Back to top |
|
 |
Mr Butcher |
Posted: Tue May 09, 2006 11:39 pm Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
maybe the DEAD.LETTER.QUEUE is defined, but i bet it is not defined to the qmgr. display the queuemanager and check the deadq attribute. _________________ Regards, Butcher |
|
Back to top |
|
 |
frankdurhine |
Posted: Wed May 10, 2006 12:12 am Post subject: |
|
|
 Novice
Joined: 04 Oct 2005 Posts: 10
|
thanks, butcher, I doublechecked this, too:
who has an other bet?
regards
Frank
Code: |
AMQ8408: Display Queue Manager details.
DESCR( ) DEADQ(DEAD.LETTER.QUEUE)
DEFXMITQ( ) CHADEXIT( )
CLWLEXIT( ) CLWLDATA( )
REPOS( ) REPOSNL( )
SSLKEYR(/var/mqm/qmgrs/QMGR1/ssl/key)
SSLCRLNL( ) SSLCRYP( )
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) QMNAME(QMGR1)
CRDATE(2005-08-02) CRTIME(14.46.34)
ALTDATE(2006-05-09) ALTTIME(14.40.40)
QMID(QMGR1_2005-08-02_14.46.34) TRIGINT(999999999)
MAXHANDS(256) MAXUMSGS(10000)
AUTHOREV(ENABLED) INHIBTEV(DISABLED)
LOCALEV(DISABLED) REMOTEEV(DISABLED)
PERFMEV(DISABLED) STRSTPEV(ENABLED)
CHAD(DISABLED) CHADEV(DISABLED)
CLWLLEN(100) MAXMSGL(4194304)
CCSID(819) MAXPRTY(9)
CMDLEVEL(530) PLATFORM(UNIX)
SYNCPT DISTL(YES)
|
|
|
Back to top |
|
 |
Mr Butcher |
Posted: Wed May 10, 2006 12:26 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
what makes me wonder is that the channel gets stopped. if the dlq is defined properly and is included in the qmgr definition, then there is no difference between non persistent messages and persistent messages, because both are put to the dlq if they can not be delivered to their target queue.
only if the dlq is not available, then non persistent messages are discarded (assuming npmspeed = fast) while for persistent messages the channel will stop.
is the dlq put-enabled? how about maxdepth / curdepth?
are there any messages in the amqerr01 log at the sending or at the receiving end related to this issue? _________________ Regards, Butcher |
|
Back to top |
|
 |
frankdurhine |
Posted: Wed May 10, 2006 1:35 am Post subject: |
|
|
 Novice
Joined: 04 Oct 2005 Posts: 10
|
the non persistent messages were not discarded but put to the dlq, when the rights were insufficient. Sorry, I messed this up. But this exposes the problem even sharper:
with acl rights:
npm are put to target queue
pm stay on source qm, while channel is stopped
without acl:
npm are put to dlq
pm stay on source qm, while channel is stopped
settings were tested on windows.
In the logs of the receiving end there is minutewise restarting in the rythm of shortretry, no error message:
Code: |
-------------------------------------------------------------------------------
05/10/06 09:49:36
AMQ9002: Channel 'QMGR2.QMGR1.1' is starting.
EXPLANATION:
Channel 'QMGR2.QMGR1.1' is starting.
ACTION:
None.
-------------------------------------------------------------------------------
05/10/06 09:49:36
AMQ9001: Channel 'QMGR2.QMGR1.1' ended normally.
EXPLANATION:
Channel 'QMGR2.QMGR1.1' ended normally.
ACTION:
None.
-------------------------------------------------------------------------------
|
At the sending end there is an errór reported:
Code: |
05/10/06 11:06:49
AMQ9556: Channel synchronization file missing or damaged.
EXPLANATION:
The channel synchronization file 'AMQRSYNA.DAT' is missing or does not
correspond to the stored channel information for queue manager 'QMGR2'.
ACTION:
Rebuild the synchronization file using the rcrmqmobj command rcrmqmobj -t
syncfile (-m q-mgr-name)
|
Obviously it is a problem of that channel syncfile.
Thanks for looking at it, and sorry, I should have seen the AMQ9556 before....  |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Tue May 16, 2006 10:06 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Check the DOUBT attribute of the sender channel status. non-persistent messages are not committed - when NPMSPEED is set to FAST. Maybe, the channel sequence number is out of sync (check it on both channel states). _________________ Regards
Hubert |
|
Back to top |
|
 |
|