MQ security - получение 2035 на одну очередь - PullRequest
Новая
       22

MQ security - получение 2035 на одну очередь

4 голосов
/ 14 октября 2010

У меня есть приложение, которое пытается поместить сообщение в очередь (LOG.TRANSACTION.IN) на удаленном администраторе очередей.Сообщение заканчивается сбоем с 2035 и помещается в DLQ на локальном администраторе очередей.В локальном администраторе очередей (QMLOCAL) приложение помещает сообщение непосредственно в SCTQ, поскольку отсутствует определение удаленной очереди.Приложение работает под идентификатором, который имеет полный доступ к MQ.Я знаю, что это не идеально, но для другого обсуждения.У нас есть mcauser на канале clusrcvr на удаленном конце (QMREMOTE), которому был предоставлен доступ к локальной очереди.Я думал, что у меня есть охрана, но, похоже, дело не в этом.Вот информация о безопасности

QMLOCAL: 

Entity application_id has the following authorizations for object SYSTEM.CLUSTER.TRANSMIT.QUEUE:  
            get  
            browse  
            put  
            inq  
            set  
            crt  
            dlt  
            chg  
            dsp  
            passid  
            passall  
            setid  
            setall  
            clr

QMREMOTE: 

Entity MY_MCAUSER has the following authorizations for object LOG.TRANSACTION.IN:  
        put  
        crt  
        setall

Любая помощь по этому вопросу будет принята с благодарностью.

Ответы [ 3 ]

2 голосов
/ 14 октября 2010

Здесь есть несколько возможностей. Поскольку сообщение заканчивается в DLQ, то мы знаем, что проблема на удаленной стороне. Если ваше приложение для размещения сгенерировало 2035, то сообщение никогда не будет помещено.

Это означает, что проблема в MCAUSER в канале CLUSRCVR. Для того, чтобы он работал, он должен иметь следующее (Предположим, что MY_MCAUSER находится в группе mqmmca):

setmqaut -m QMREMOTE -g mqmmca -t qmgr -all +connect +inq +setall
setmqaut -m QMREMOTE -g mqmmca -n 'LOG.TRANSACTION.IN' -t queue -all +put +setall

Не имеет отношения к вашему 2035, канал также нуждается в
setmqaut -m QMREMOTE -g mqmmca -n 'SYSTEM.CLUSTER.COMMAND.QUEUE' -t queue -all +put +setall
просто функционировать в кластере. В зависимости от вашей версии канал MCAUSER может также нуждаться в доступе к SYSTEM.CHANNEL.SYNCQ (варианты v7).

Простой способ узнать наверняка - включить события авторизации.
ALTER QMGR AUTHOREV(ENABLED)

События авторизации сообщают вам идентификатор, который не удался, объект, в котором он произошел (QMgr, очередь и т. Д.), Выполняемый вызов API и использованные опции.

Затем установите SupportPac MS0P в WMQ Explorer. Это отформатирует двоичные сообщения о событиях PCF в удобочитаемую форму, и будет действительно очевидно, в чем именно заключается проблема.

В этом случае вполне вероятно, что либо a) MCAUSER не хватает + setall на QMgr, либо b) это v7, а MCAUSER не хватает соответствующего разрешения на S.C.SQ, как отмечено выше.

0 голосов
/ 03 марта 2014

Вы также можете решить эту проблему, установив mcauser ('mqm') .. Я смог преодолеть ошибку 2035. 

Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)

Esp спасибо моему Билалу Ахмаду (PSE)

0 голосов
/ 17 октября 2010

Я сделал маленькую картинку. Надеюсь, это немного прояснит ситуацию.

http://imgur.com/92NJm.jpg

...