从mq客户端运行Linux / MQSC命令

前端之家收集整理的这篇文章主要介绍了从mq客户端运行Linux / MQSC命令前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
好的,我想检查一下我是否可以远程在MQ服务器中运行一些OS或MQSC命令.只要我知道,这可以通过SYSTEM.ADMIN.SVRCONN来完成.为此,我将一个远程队列管理器添加到我的WebSphere MQ客户端.我将队列管理器名称放在具有适当IP的服务器上,但是当我使用SYSTEM.ADMIN.SVRCONN作为通道名称时,我得到:通道名称无法识别(AMQ4871)错误.

另外,如果我有一个像MY.CHANNEL.NAME这样的频道名称,并且它是一个服务器连接通道,mqm作为其MCAUSER,我可以通过服务器上的这个频道运行一些命令(MQSC或OS)吗?

谢谢.

EDIT1

我正在使用WebSphere MQ v.7.0

通过“我将远程队列管理器添加到我的WebSphere MQ客户端”,我的意思是我向MQ Explorer添加了一个远程队列管理器.

EDIT2

我想在这个编辑中更准确地解释我的问题.我想通过MQ Explorer连接到远程Qmanager.我知道Qmanager的名字和它的知识产权.此外,远程Qmanager还具有SYSTEM.ADMIN.SVRCONN和SYSTEM.AUTO.SVRCONN通道.当我检查CHLAUTH这些频道时,我得到了:

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
     6 : dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
AMQ8414: Display Channel details.
   CHANNEL(SYSTEM.AUTO.SVRCONN)            CHLTYPE(SVRCONN)
   MCAUSER( )

正如你在这里看到的,我应该能够通过这两个通道连接并运行一些命令.但是当我在远程配置中选择SYSTEM.ADMIN.SVRCONN作为通道名称时,我得到:通道名称无法识别(AMQ4871),当我选择SYSTEM.AUTO.SVRCONN作为通道名称时,我得到:您无权执行此操作( AMQ4036).

任何的想法?

解决方法

I add a remote Queue Manager to my WebSphere MQ client.

我完全不确定这意味着什么. MQ Explorer保留队列管理器定义的列表. MQ Client只是一个用于建立连接的库.

如果您的意思是将远程队列管理器添加到MQ Explorer,那么它是有意义的.除了在资源管理器中定义连接之外,您还必须在队列管理器中配置连接.这意味着定义SYSTEM.ADMIN.SVRCONN通道或具有您选择的名称的通道,定义和启动监听器.如果您使用的是7.1或更高版本的队列管理器(在询问MQ时列出版本总是很好),那么您还需要创建CHLAUTH规则以允许连接,并使用另一个CHLAUTH规则来允许具有管理权限的连接.或者完全禁用或禁用CHLAUTH规则,但不建议这样做.

If I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER,can I run some commands (MQSC or OS) through this channel on the server?

也许.

开箱即用,MQ拒绝所有客户端连接.有拒绝管理连接的CHLAUTH规则,以及拒绝SYSTEM.ADMIN.SVRCONN以外的任何SYSTEM.*通道的其他CHLAUTH规则.由于管理员连接被拒绝,非管理员用户必须先使用SET AUTHREC或setmqaut命令配置访问权限,然后才能使用SYSTEM.ADMIN.SVRCONN,因此MQ被称为“默认安全”.

当您创建MY.CHANNEL.NAME并以管理员身份连接时,如果启用了CHLAUTH,则连接将被拒绝.您必须添加新的CHLAUTH规则,例如……

SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD)

…为了允许管理员连接.

(注意:MQ CHLAUTH阻止规则使用黑名单方法.默认规则阻止来自所有通道的* MQADMIN.上面列出的规则会覆盖默认规则,因为通道名称更具体,它阻止* NOBODY – 这是一个列表用户ID不包含mqm或任何其他管理用户ID.这很奇怪,但这就是它的工作方式.)

有关此主题的更多信息,请参阅http://t-rob.net/links,特别是Morag关于CHLAUTH规则的会议报告是必读的.

20150506更新
回应编辑#1&原问题中的#2如下:

第一个编辑说QMgr是v7.0,第二个编辑表明QMgr定义了CHLAUTH记录.由于CHLAUTH直到v7.1才可用,这两个陈述是互斥的 – 它们不可能都是真的.提供MQ服务器或客户端的版本时,最好粘贴到dspmqver的输出中.如果问题与GSKit,Java代码或基本代码之外的其他组件有关,那么dspmqver -a会更好.

问题更新中提供的MQSC输出完全解释了错误.

dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.

正如Morag所说,SYSTEM.ADMIN.SVRCONN无法使用,因为它尚未定义.

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)

发生auths错误是因为此规则阻止任何未明确覆盖的SYSTEM.* SVRCONN通道的任何连接. SYSTEM.ADMIN.SVRCONN的CHLAUTH规则优先,因为它更明确,并允许与该通道的非管理员连接. SYSTEM.AUTO.SVRCONN缺少类似的覆盖规则意味着它被上面列出的SYSTEM.*频道的现有规则拒绝.

如前所述,强烈建议您访问链接的网站并阅读Morag关于MQ v7.1安全性和CHLAUTH规则的会议演示文稿.它解释了如何应用CHLAUTH规则,优先级如何工作,也许最重要的是,如何使用MATCH(RUNCHECK) parameter验证它们.

要正确执行MQ安全性,您至少需要以下内容

>定义一个名称不以SYSTEM.*开头的频道,并设置MCAUSER(‘* NOBODY’).
>定义CHLAUTH规则以允许连接到该通道,根据需要映射MCAUSER.
>如果您希望使用mqm或admin访问权限连接到通道,请定义CHLAUTH规则以对通道进行身份验证,最好使用TLS和证书.

由于Morag和我的演讲中解释的原因,有几件事你不想做.这些包括

>使用SYSTEM.AUTO.SVRCONN进行任何合法连接.
>就此而言,使用SYSTEM.*任何东西(SYSTEM.ADMIN.SVRCONN或SYSTEM.BROKER.*除外)进行合法连接.
>允许未经身份验证的管理员连接.
>禁用CHLAUTH规则.
>禁用OAM.

我希望人们学习MQ安全性,并且非常好地学习它.但是,作为一名专门研究它的顾问,我必须告诉你,即使是雇用我来提供现场课程并帮助他们实施的客户也很难将其锁定.从这个事实中可以看到两个见解.

首先,如果您没有足够的时间来加快MQ安全性,那么实现将是不安全的.要研究这个主题,以便了解所有部分如何很好地融合在一起,以设计一个合适的安全模型,需要使用QMgr进行实际操作培训,您可以构建,锤击,拆除,再次构建等等.专门的实践研究,或数月或数年的随意学习.我的建议是获得MQ Advanced for Developers.它功能齐全,免费,并且具有您现在正在使用的v7.1或v7.5 QMgr上的控件的超集.

第二个见解是,没有学习MQ(或任何其他IT)安全性的捷径.如果它被认为只是一个配置问题,那么几乎可以保证在实施时不安全.如果将其视为学习可用于身份验证,授权和策略实施的所有不同控件,然后了解它们如何进行交互,并且如果将安全性作为实践规则进行处理,则可以实现一些有意义的安全性.

解决第二个问题需要对教育进行投资.阅读演示文稿,并在您管理的测试QMgr上实时测试各种控件.了解哪些错误记录到哪些错误日志,生成事件消息以及生成哪种类型的事件.获取SupportPacs中的一些诊断工具,例如我最喜欢的MS0P之一,并熟悉它们.考虑参加MQ Tech Conference(在那里你可以见到许多在这里回答SO的人)进行更深入的培训.

如果您(或您的雇主)还没有准备好进行深入的技能培养,或者正在尝试在即将到来的项目截止日期前学习这一点,那么请考虑在需要的基础上雇用深入的MQ安全技能,因为依赖于just-in-这个主题的在职培训时间是不安全网络的一个秘诀.

猜你在找的Linux相关文章