Безопасность MQ - получение 2035 в одной очереди

У меня есть приложение, которое пытается поместить сообщение в очередь (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

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


ibm-mq
person Matt    schedule 14.10.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Здесь есть несколько возможностей. Поскольку сообщение попадает в 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 в удобочитаемую форму, и будет действительно очевидно, в чем именно заключается проблема.

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

person T.Rob    schedule 14.10.2010
comment
Я устанавливаю последнюю версию MQ Explorer и сообщу вам о безопасности. Странная часть заключается в том, что у нас одинаковые разрешения по всем направлениям, используя группу MQMMCA с разрешениями, предоставленными с вашего веб-сайта. Это единственный случай в нашей среде, когда диспетчер очередей помещает в удаленную очередь, которая не является кластеризованной или имеет qr, определенный локально. - person Matt; 14.10.2010
comment
Кроме того, это MQ 6.0.2.8 на AIX. - person Matt; 14.10.2010
comment
Мне действительно любопытно посмотреть, что вы обнаружите, когда посмотрите на сообщение о событии. Какая версия и пакет исправлений WMQ на удаленном QMgr? - person T.Rob; 14.10.2010
comment
Ха! Какое время. Хорошо, по крайней мере, это не проблема S.C.SQ. Вы знаете об окончании обслуживания версии 6.0 в сентябре 2011 года, верно? Пожалуйста, поощряйте переход на версию 7, чтобы в следующем году вас не застали без поддержки. - person T.Rob; 14.10.2010
comment
Мы находимся в активном проекте по переходу на v7. Это огромный процесс! - person Matt; 15.10.2010
comment
Итак, теперь я немного смущен. Я вижу 2035 с помощью Проводника, и вот результат: Параметры открытия: [out passid] - person Matt; 15.10.2010
comment
Извините, время редактирования истекло: Параметры открытия: [out passid] Идентификатор пользователя: generic_id (у которого нет доступа к удаленному qmgr), Тип приложения: UNIX, Имя приложения: DataFlowEngine64. Так что это ясно имеет смысл, почему он получает неавторизованный. Я предполагаю, что у меня есть вопрос, почему он все еще использует этот идентификатор, когда он сталкивается с каналом, на котором установлен mcauser? Контекстная безопасность на канале не включена, поэтому я ожидаю, что все сообщения будут авторизованы этим mcauser. - person Matt; 15.10.2010
comment
Итак, перечисленные выше сообщения были на удаленном qmgr. Я только что смог получить сообщения от локального qmgr, который также получал сообщения, отправленные в DLQ, и увидел следующее: Классификатор причины: Открытие не авторизовано, Имя очереди: LOG.TRANSACTION.IN, Параметры открытия: out passid, User Идентификатор: MY_MCAUSER, Тип приложения: Unix, Имя приложения: amqrmppa, Имя диспетчера очереди объектов: QMREMOTE - person Matt; 15.10.2010
comment
Вы уверены, что у вас есть это право? Идентификатор процесса канала — amqrmppa, так что это должен быть удаленный QMgr, а не локальный. DataFlowEngine64 — это исполнительная группа брокера, поэтому это должен быть локальный QMgr. Логично, что брокер будет использовать идентификатор пароля. В вашем комментарии похоже, что channe тоже использует passid, и это кажется неправильным. - person T.Rob; 16.10.2010
comment
Если вы получили локальный и удаленный реверс, возможно ли, что запрос поступает к брокеру, но ответ не работает? Дайте брокеру +passid в его выходных очередях (или XMitQ, если приложение использует динамические очереди ответов). Это решает проблему на стороне боркера, но не уверен, почему вы видите +passid от amqrmppa, если только вы не прочитали его неправильно. - person T.Rob; 16.10.2010
comment
Я сделал маленькую картинку. Надеюсь, это немного прояснит ситуацию. imgur.com/92NJm.jpg - person Matt; 18.10.2010

arrow_upward
0
arrow_downward

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

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

person Matt    schedule 17.10.2010
comment
Привет, Мэтт! На картинке в верхнем поле показано имя процесса amqrmppa, а идентификатор MQMCA, как мне кажется, находится в MCAUSER CLUSRCVR. Поскольку amqrmppa — это процесс, который запускает входящие каналы, все это указывает на проблему авторизации с ответным сообщением, а не с запросом. (Предполагается, что поток — это запрос сверху вниз, за ​​которым следует ответ снизу вверх.) - person T.Rob; 21.10.2010
comment
В нижнем поле идентификатор процесса DataFlowEngine64 указывает, что у брокера возникают проблемы с открытием очереди вывода. Я предполагаю, что брокер повторно ставит выходные данные в очередь на DLQ, поскольку обычно локальные приложения не помещают в очередь выходные сообщения автоматически. Итак, в целом, я думаю, что поток сообщений сверху вниз работает, поток ответов, кажется, истощается. - person T.Rob; 21.10.2010

arrow_upward
0
arrow_downward

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

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

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

person Digital Alchemist    schedule 03.03.2014