管理和配置指南

JBoss 企业级应用程序平台 6.2

适用于红帽 JBoss 企业版应用程序平台 6

Sande Gilda

David Le Sage

Red Hat Engineering Content Services

Darrin Mison

David Ryan

Misty Stanley-Jones

摘要

本书是安装和配置红帽 JBoss 企业版应用程序平台 6 及其补丁的指南。

第 1 章 简介

1.1. 关于 JBoss 企业版应用程序平台 6(JBoss EAP 6)

红帽 JBoss EAP 6 是一个构建在开放标准上并和 Java EE 6 规格兼容的快速的、安全的、功能强大的中间件平台。它集成 JBoss AS 7 和高可用性的群集、强大的 messaging 系统、分布式缓存以及其他技术来创建稳定、可扩充的和快速的平台。
新的模块化结构允许服务只在需要时才启用,这显著地提高了启动速度。管理控制台和管理命令行接口不需要手动编辑 XML 配置文件,并添加了创建脚本和自动化任务的能力。此外,它也包含了 API 和开发框架以快速开发安全的、强大的和可扩充的 Java EE 应用程序。

1.2. JBoss EAP 6 的功能

表 1.1. 6.1.0 功能

功能 描述
Java 认证 已认证的 Java EE 6 Full 和 Web 配置规格的实现。
受管域
  • 受管域提供对多个服务器实例和物理主机的集中式管理,而独立服务器则只允许单个的服务器实例。
  • 配置、部署、套接字绑定、模块、扩展和系统属性都可以根据每个服务器组进行管理。
  • 应用程序的安全性,包括安全域都集中管理以简化配置。
管理控制台和管理 CLI 管理控制台和管理 CLI 是管理域或独立 EAP 实例的全新接口。你不再需要编辑 XML 文件。管理 CLI 甚至可以提供批处理模式,你可以编写脚本并自动化管理任务。
简化的目录格式 EAP 的目录结构已经进行了简化。modules/ 目录现在包括了应用服务器模块,而不是使用公用的和服务器专有的 lib/ 目录。domain/standalone/ 目录包含了域和独立部署的 artifact 和配置文件。
模块化的类加载机制 你根据需要来加载和卸载模块以提高性能和增强安全性、以及更快的启动和重启速度。
流线型的数据源管理 数据库驱动可以像其他服务一样部署。此外,数据源可以在管理控制台和管理 CLI 里直接创建和管理。
更快的启动和停止速度 JBoss EAP 6 使用更少的资源且对系统资源的利用率非常高。这对于开发人员尤其有益处。

1.3. 关于 JBoss EAP 6 操作模式

JBoss EAP 提供两种操作 JBoss EAP 实例的模式,它可以引导为独立服务器(Standalone Server)受管域(Managed Domain)。每种模式都是为了满足不同商业场景的需要。它让您可以选择单个服务器安装还是多服务器管理以满足商业需求及自动化管理过程。
受管域或独立服务器的选择取决于如何管理服务器而不是它们为满足最终用户请求而提供的功能。对于高可用性(HA)群集这种区分尤其重要。理解 HA 功能和运行独立服务器还是受管域并不相关是很重要的,也就是说,一组独立服务器也可以组成 HA 群集。

1.4. 关于独立服务器

独立服务器是 JBoss EAP 的两种操作模式之一。独立服务器模式以独立的进程运行,它和以前的 JBoss EAP 版本的唯一运行模式类似。
作为独立服务器运行的 JBoss EAP 实例只是一个单一实例,但也可以运行在群集配置里。

1.5. 关于受管域

受管域是 JBoss EAP 的两种操作模式之一。它是一个通过单点控制来管理多个 JBoss EAP 6 实例的模式。
集中管理的服务器集合被称为域的成员。
域控制器是控制域的中心点。它确保每个服务器都可以按照域的管理策略进行配置。域控制器也是一个主机控制器。主机控制器是运行 domain.shdomain.bat 脚本的物理或虚拟主机。与域控制器不同,我们配置主机控制器来委托域管理任务。每台主机上的主机控制器和域控制器交互来控制运行在主机上的应用服务器实例的生命周期,并协助域控制器进行管理。每个主机都可以包含多个服务器组。服务器组是一系列安装了 JBoss EAP 6 的服务器实例,并将其作为一个整体来管理和配置。既然域控制器管理部署在服务器组上的配置和应用程序,服务器组里的每台服务器都共享相同的配置和部署。
域控制器、单个主机控制器和多个服务器是可以运行在相同物理系统上的相同 JBoss EAP 6 实例里的。主机控制器捆绑在专门的物理(或虚拟)主机上。如果使用不同的配置,您可以在相同的硬件上运行多个主机控制器,所以端口和其他资源并不会冲突。
受管域有一个域控制器,三个主机控制器以及三个服务器组。服务器是服务器组的成员,可以位于域里任意一个主机控制器上。

图 1.1. 受管域的图形表示方式

1.6. 关于域控制器

域控制器是一个充当域集中管理点的 JBoss EAP 6 服务器实例。您可以配置主机控制器为域控制器。域控制器的主要职责是:
  • 维护域的集中管理策略
  • 确保所有主机控制器可以知晓其当前的内容。
  • 协助主机控制器以确保所有运行的 JBoss EAP 6 实例都按照这个策略进行配置
集中管理策略默认保存在 domain/configuration/domain.xml 文件里,它位于域控制器的主机文件系统上解压的 JBoss EAP 6 安装目录里。
domain.xml 必须位于作为域控制器运行的主机控制器的 domain/configuration/ 目录里。这个文件对于不是作为域控制器的主机控制器上的安装来说并不是强制的,虽然 domain.xml 文件的出现也没有害处。domain.xml 文件包含不同配置集的配置,它们可都用于运行在域里的服务器实例。配置集的配置包含组成配置集的不同子系统的详细配置。域配置也包含对套接字组和服务器组的定义。

1.7. 关于域控制器失效切换

如果由于某种原因域控制器出现故障,你可以配置和提名任何主机控制器为域控制器。

1.8. 关于主机控制器

当脚本 domain.shdomain.bat script 运行在主机上时会启动主机控制器。主机控制器的主要职责是管理服务器。它委托域管理任务并负责启动和停止运行在主机上的单独的应用服务器进程。它和域控制器进行交互以帮助管理服务器和域控制器间的通讯。域里多个主机服务器可以和单个域控制器进行交互。因此,所有的主机控制器和运行在单一域模式下的服务器实例可以拥有单一的域控制器且必须属于相同的域。
每个主机控制器默认都从主机的文件系统上解压的 JBoss EAP 6 安装的 domain/configuration/host.xml 文件读取配置。host.xml 包含下列特定主机专有的配置信息:
  • 从这个安装位置运行的实际的 JBoss EAP 6 实例名称的列表
  • 任何下列的配置:
    • 主机控制器如何联系域控制器来注册自身并访问域配置
    • 如何找到并联系远程的域控制器
    • 告诉主机控制器自身充当域控制器
  • 这些条目是本地物理安装的配置。例如,domain.xml 里声明的命名接口定义可以映射到 host.xml 里实际的主机专有的 IP 地址。domain.xml 里的绝对路径名可以映射到 host.xml 里实际的文件系统路径。

1.9. 关于服务器组

服务器组是一个进行集中管理和配置的服务器实例集合。在受管域里,每个应用服务器实例都属于一个服务器组,即使它只是唯一的成员。组里的服务器实例共享相同的配置集和部署的内容。域控制器和主机控制器对域里的每个服务器组的所有服务器实例都强制实施标准的配置。域可以由多个服务器组组成。不同的服务器组可以用不同的配置集和部署来进行配置。例如,域里可以有提供不同服务的不同服务器层。不同的服务器组也可以有相同的配置集和部署,例如,为了在升级应用程序时避免服务中断,可以首先升级一个服务器组,然后再升级第二个服务组。
下面是一个服务器组定义示例:
     
<server-group name="main-server-group" profile="default">
 <socket-binding-group ref="standard-sockets"/>
  <deployments>
   <deployment name="foo.war_v1" runtime-name="foo.war"/>
   <deployment name="bar.ear" runtime-name="bar.ear"/>
  </deployments>
</server-group>

服务器组包括下列强制的属性:
  • name:服务器组的名称
  • profile:服务器组的配置集的名称
服务器组包含下列可选属性:
  • socket-binding-group:用于组里服务器的默认套接字绑定组的名称。在 host.xml 里可以对每个服务器覆盖这个名称。如果在 server-group 元素里没有提供 socket-binding-group 名称,那您必须在 host.xml 里为每个服务器提供一个名称。
  • deployments:部署在组里服务器上的部署内容
  • system-properties:组里服务器上设置的系统属性
  • jvm:组里所有服务器的默认 JVM。主机控制器将这些设置和 host.xml 里的其他配置进行合并以生成启动服务器的 JVM 的设置。

1.10. 关于 JBoss EAP 6 配置集

以前 JBoss EAP 版本里使用的配置集的概念不再使用了。JBoss EAP 6 现在使用更少的配置文件来保存配置信息。
模块和驱动是根据需要加载的,所以以前 JBoss EAP 6 版本里让服务器更高效地启动的 default 配置集的概念不再适用。在部署期间,模块依赖关系将被确定、排序且由服务器或域控制器进行解析,并按正确的顺序加载。在部署卸载期间,当没有部署需要模块时,它将被卸载。
您可以从配置里删除子系统来禁用模块或手动卸载驱动或其他服务。然而,大多数情况下这是不必要的。如果你的应用程序没有使用模块,它不会被加载。

第 2 章 应用服务器管理

2.1. 启动和停止 JBoss EAP 6

2.1.2. 将 JBoss EAP 6 作为独立服务器启动

概述

本节涵盖将 JBoss EAP 6 作为独立服务器启动的步骤

过程 2.1. 将平台服务作为独立服务器启动

  1. 对于红帽企业版 Linux。

    运行命令:EAP_HOME/bin/standalone.sh
  2. 对于 Microsoft Windows 服务器。

    运行命令:EAP_HOME\bin\standalone.bat
  3. 可选:指定其他的参数。

    要查看传入启动脚本的其他参数,请使用 -h 参数。
结果

JBoss EAP 6 服务器实例已启动。

2.1.3. 将 JBoss EAP 6 作为受管域启动

操作顺序

域控制器必须在域里任何服务器组里的任何从服务器之前启动。先在域控制器上,然后在每个关联的主机控制器和其他主机上使用这个过程。

过程 2.2. 将平台服务作为受管域启动

  1. 对于红帽企业版 Linux。

    运行命令: EAP_HOME/bin/domain.sh
  2. 对于 Microsoft Windows 服务器。

    运行: EAP_HOME\bin\domain.bat
  3. 可选:传递其他参数到启动脚本里。

    请使用 -h 参数来获取传递到启动脚本里的参数列表。
结果

JBoss EAP 6 受管域实例已启动。

2.1.4. 用替代配置启动 JBoss EAP 6

如果你没有指定配置文件,服务器将用默认的文件启动。然而,当你启动服务器时,你可以手动指定一个配置文件。启动过程会稍有不同,这取决于你是使用受管域还是独立服务器、以及你使用的操作系统。

前提条件

  • 在使用替代配置文件之前,请将 default 配置作为模版使用。对于受管域,配置文件必须位于 EAP_HOME/domain/configuration/ 目录。对于独立服务器,配置文件必须位于 EAP_HOME/standalone/configuration/ 目录。

注意

EAP_HOME/docs/examples/configs/ 目录里包含了几个配置示例。请用这些例子来启用额外的功能,如群集或 Transactions XTS API。

过程 2.3. 用其他配置启动实例

  1. 独立服务器

    对于独立服务器,请将配置文件的名称作为 --server-config 参数的选项。配置文件必须位于 EAP_HOME/standalone/configuration/ 目录里,而且您需要指定相对这个目录的路径。

    例 2.1. 在红帽企业版 Linux 里对独立服务器使用其他的配置文件

    [user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml
    这个例子使用了 EAP_HOME/standalone/configuration/standalone-alternate.xml 配置文件。

    例 2.2. 在 Microsoft Windows 服务器里对独立服务器使用其他的配置文件

    C:\EAP_HOME\bin>standalone.bat --server-config=standalone-alternate.xml
    这个例子使用了 EAP_HOME\standalone\configuration\standalone-alternative.xml 配置文件。
  2. 受管域

    对于受管域,请为 --domain-config 参数提供配置文件的名称。这个文件必须位于 EAP_HOME/domain/configuration/ 目录,且您需要指定相对这个目录的路径。

    例 2.3. 在红帽企业版 Linux 里对受管域使用其他的配置文件

    [user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml
    这个例子使用了 EAP_HOME/domain/configuration/domain-alternate.xml 配置文件。

    例 2.4. 在 Microsoft Windows 服务器里对受管域使用其他的配置文件

    C:\EAP_HOME\bin>domain.bat --domain-config=domain-alternate.xml 
    
    
    这个例子使用了 EAP_HOME\domain\configuration\domain-alternate.xml 配置文件。
结果

使用替代配置运行了 JBoss EAP 6。

2.1.5. 停止 JBoss EAP 6

您停止 JBoss EAP 6 的方式取决于它是如何启动的。本节涵盖停止交互式启动的实例、停止作为服务启动的实例以及停止用脚本复制至后台进程的实例。

注意

本节不会涉及在受管域里停止服务器或服务器组。相关信息请参考 第 2.2.3 节 “使用管理控制台停止服务器”

过程 2.4. 停止 JBoss EAP 6 的独立服务器实例

  1. 停止从命令提示交互式启动的实例。

    在 JBoss EAP 6 运行的终端窗口里按 Ctrl-C
  2. 停止作为操作系统服务启动的实例。

    根据操作系统使用下列步骤。
    • 红帽企业版 Linux

      对于红帽企业版 Linux,如果您已经编写了服务脚本,请使用它的 stop 功能。这需要编写到脚本里。然后您可以使用 service scriptname stop,这里的 scriptname 是脚本名称。
    • Microsoft Windows Server

      在 Microsoft Windows 里,使用 net service 命令,或者通过控制面板里的 Services 小程序来停止服务。
  3. 停止在背景运行的示例(红帽企业版 Linux)

    1. 从进程列表里找到实例。一个选择是运行 ps aux |grep "[j]ava -server"。它会为运行在本地主机上的每个 JBoss EAP 6 实例返回一个结果。
    2. 运行 kill process_ID 给进程发送 TERM 信号,这里的 process_ID 是上面的 ps aux 命令的第二个字段的编号。
结果

每个方法都可以干净地关闭 JBoss EAP 6,所以不会丢失数据。

2.1.6. 服务器启动参数和开关参考

应用服务器启动脚本在运行时接受其他参数和开关。这些参数允许服务器根据 standalone.xmldomain.xmlhost.xml 配置文件里定义的其他配置启动。这可能包括用其他套接字绑定集或次级配置启动服务器。在启动时使用 help 开关可以参考这些可用的参数列表。

例 2.5. 

下面的例子和 第 2.1.2 节 “将 JBoss EAP 6 作为独立服务器启动” 里解释的服务器启动类似,但添加了 -h--help 开关。下表解释了 help 开关的结果。
[localhost bin]$ standalone.sh -h

表 2.1. 运行时开关和参数表

参数或开关 描述
--admin-only 设置服务器的运行类型为 ADMIN_ONLY。这将导致它打开管理接口并接受管理请求,但不会启动其他运行时服务或接受最终用户请求。
-b=<value> 设置系统属性 jboss.bind.address 为给定的值。
-b <value> 设置系统属性 jboss.bind.address 为给定的值。
-b<interface>=<value> 设置系统属性 jboss.bind.address.<interface> 为给定的值。
-c=<config> 要使用的服务器配置文件的名称。默认是 standalone.xml
-c <config> 要使用的服务器配置文件的名称。默认是 standalone.xml
--debug [<port>] 激活调试模式并用可选参数来指定端口。只有启动脚本支持才可以使用。
-D<name>[=<value>] 设置系统属性。
-h 显示帮助信息并退出。
--help 显示帮助信息并退出。
--read-only-server-config=<config> 要使用的配置文件的名称。它和 '--server-config' 和 '-c' 不同,因为原始文件不会被覆盖。
-P=<url> 从给定 URL 加载系统属性。
-P <url> 从给定 URL 加载系统属性。
--properties=<url> 从给定 URL 加载系统属性。
-S<name>[=<value>] 设置安全性属性。
--server-config=<config> 要使用的服务器配置文件的名称。默认是 standalone.xml
-u=<value> 设置系统属性 jboss.default.multicast.address 为给定的值。
-u <value> 设置系统属性 jboss.default.multicast.address 为给定的值。
-V 显示应用服务器版本并退出。
-v 显示应用服务器版本并退出。
--version 显示应用服务器版本并退出。

2.2. 启动和停止服务器

2.2.1. 用管理 CLI 启动或停止服务器。

您可以用管理 CLI 或管理控制台来启动和停止服务器。这两个管理工具都允许您控制单个独立服务器实例,或者选择性地管理受管域部署里的多个服务器。如果您在使用管理控制台,请参考 第 2.2.2 节 “使用管理控制台启动服务器” 里的说明。如果您在使用管理 CLI,针对独立服务器和受管域实例的过程是不一样。
用管理 CLI 启动或停止独立服务器。

独立服务器实例可以用命令行脚本启动,并用 shutdown 命令在管理 CLI 里关闭。如果你再次需要这个实例,请按照 第 2.1.2 节 “将 JBoss EAP 6 作为独立服务器启动” 里描述的过程再次启动。

例 2.6. 通过管理 CLI 停止独立服务器实例

[standalone@localhost:9999 /] shutdown
用管理 CLI 启动或停止受管域

如果你在运行受管域,管理控制台会允许你选择启动或关闭域里的特定服务器。这包括整个域里的服务器组,以及主机上的特定服务器实例。

例 2.7. 通过管理 CLI 停止受管域里的服务器主机

和独立服务器实例类似, shutdown 命令用于关闭声明的受管域主机。这个例子通过在调用关闭操作前声明实例名来关闭名为 master 的服务器主机。请用 tab 健来协助完成字符串并开放可见变量如可用的主机值。
[domain@localhost:9999 /] /host=master:shutdown

例 2.8. 通过管理 CLI 停止受管域里的服务器组

这个例子通过在调用 startstop 操作前声明组启动了一个名为 main-server-group 的默认服务器组。请用 tab 健来协助完成字符串并开放可见变量如可用的主机组名的值。
[domain@localhost:9999 /] /server-group=main-server-group:start-servers
[domain@localhost:9999 /] /server-group=main-server-group:stop-servers

例 2.9. 通过管理 CLI 停止受管域里的服务器实例

这个例子通过在调用 startstop 操作前声明主机启动和停止了 master 主机上的一个名为 server-one 的服务器实例。请用 tab 健来协助完成字符串并开放可见变量如可用的主机和服务器配置的值。
[domain@localhost:9999 /] /host=master/server-config=server-one:start
[domain@localhost:9999 /] /host=master/server-config=server-one:stop

2.2.2. 使用管理控制台启动服务器

过程 2.5. 启动服务器

  1. 进入管理控制台里的 Server Instances

    1. 从控制台的顶部选择 Runtime 标签页。
  2. 选择服务器

    Server Instances 列表里,选择要启动的服务器。正在运行的服务器会用一个复选框标记表示。
    在这个列表的实例上悬停会在服务器细节下面以蓝色字体显示选项。
  3. 点击 Start

    要启动这个实例,请在 Start Server 文本出现时点击它。然后会出现一个确认对话框,点击 Confirm 按钮启动服务器。
结果

所选的服务器已启动并在运行中。

2.2.3. 使用管理控制台停止服务器

过程 2.6. 使用管理控制台停止服务器

  1. 进入管理控制台里的 Hosts, groups and server instances

    1. 从控制台的顶部选择 Runtime 比标签页。Topology 标签页里的主面板会显示可用的服务器实例。
  2. 选择服务器

    Server Instances 列表里,选择要停止的服务器。正在运行的服务器用一个复选框标记表示。
  3. 点击 Stop Server 文本

    点击当您将鼠标悬停在服务器条目时出现的 Stop Server 文本。确认对话框将会出现。
  4. 点击 Confirm 按钮来停止服务器。
结果

所选的服务器已停止。

2.3. 文件系统路径

2.3.1. 文件系统路径

JBoss EAP 6 使用了文件系统路径的逻辑名称。domain.xmlhost.xmlstandalone.xml 配置都包含一个可以声明路径的部分。然后配置的其他部分可以通过逻辑名称引用这些路径,避免了为每个实例声明绝对路径。这有利于配置和管理,因为它允许将专有的主机配置解析为同一的逻辑名称。
例如,日志子系统配置包括对 jboss.server.log.dir 路径的引用,它指向服务器的 log 目录。

例 2.10. 日志目录的相对路路径示例

<file relative-to="jboss.server.log.dir" path="server.log"/>

JBoss EAP 6 自动提供大量的标准路径而无需用户在配置文件进行配置。

表 2.2. 标准路径

描述
jboss.home.dir JBoss EAP 6 的根目录。
user.home 用户的主目录。
user.dir 用户的当前工作目录。
java.home Java 的装路径
jboss.server.base.dir 单独服务器实例的根目录。
jboss.server.data.dir 服务器用于持久性数据文件存储的目录。
jboss.server.config.dir 包含服务器配置的目录。
jboss.server.log.dir 服务器用于日志文件存储的目录。
jboss.server.temp.dir 服务器用于临时文件存储的目录。
jboss.controller.temp.dir 主机控制器用于临时文件存储的目录。
用户可以在配置文件里添加 path 元素来添加自己的路径,或覆盖除了上面前 5 个路径外的所有路径。下面的例子展示了相对于独立服务器实例的根目录的新的相对路径声明。

例 2.11. 相对路径的格式

<path name="examplename" path="example/path" relative-to="jboss.server.data.dir"/>

路径声明的结构使用下列属性。

表 2.3. 路径属性

属性 描述
name 路径的名称。
path 实际的文件系统路径。它将被当作绝对路径,除非指定了 relative-to 属性,此时它会被当作相对该路径的值。
relative-to 可选属性,它指定之前命名路径的名称,或者系统提供的标准路径中的其中一个。
domain.xml 配置文件里的 path 元素只要求 name 属性。它不需要包括指定下面例子里所展示的实际文件系统路径的信息。

例 2.12. 域路径示例

<path name="example"/>

这个配置简单地声明一个名为 example 的路径,可供 domain.xml 配置的其他部分引用。example 声明的实际文件系统位置是加入域组的主机实例的 host.xml 配置文件所专有的。如果使用了这个方法,每台主机的 host.xml 里必须有一个 path 元素来指定实际的文件系统路径。

例 2.13. 主机路径示例

<path name="example" path="path/to/example" />

standalone.xml 里的 path 元素必须包括实际文件系统路径的规格。

2.4. 配置文件历史

2.4.1. 关于 JBoss EAP 6 配置文件

JBoss EAP 6 的配置和以前版本已经有了很大的修改。最显著的不同是使用了简化的配置文件结构,它包含下面列出的一个或多个文件。

表 2.4. 配置文件的位置

服务器模式 位置 目的
domain.xml EAP_HOME/domain/configuration/domain.xml 这是受管域的主配置文件。只有域主控制器可以读取这个文件。对于其他成员,它可以被删除。
host.xml EAP_HOME/domain/configuration/host.xml 这个文件包含了受管域里的物理主机专有的配置细节,如网络接口、套接字绑定、主机名称和其他主机专有的细节。host.xml 文件包含了 host-master.xmlhost-slave.xml 的全部功能,正如下面所描述的。这个文件没有出现在独立服务器里。
host-master.xml EAP_HOME/domain/configuration/host-master.xml 这个文件包含了作为受管域里主服务器运行所需的配置细节。这个文件不会出现在独立服务器里。
host-slave.xml EAP_HOME/domain/configuration/host-slave.xml 这个文件包含了作为受管域里从服务器运行所需的配置细节。这个文件不会出现在独立服务器里。
standalone.xml EAP_HOME/standalone/configuration/standalone.xml 这是用于独立服务器的默认配置文件。它包含了独立服务器的所有信息,如子系统、网络、部署、套接字绑定和其他配置细节。当您启动独立服务器时会自动使用这个配置。
standalone-full.xml EAP_HOME/standalone/configuration/standalone-full.xml 这是用于独立服务器的配置示例。它包含对每种可能的子系统的支持,除了那些要求高可用性的子系统。要使用它,请停止您的服务器并用下列命令重启:EAP_HOME/bin/standalone.sh -c standalone-full.xml
standalone-ha.xml EAP_HOME/standalone/configuration/standalone-ha.xml 这个配置文件示例启用所有的默认子系统并为独立服务器添加了 mod_cluster 和 JGroups 子系统,所以它可以参与高可用性或负载平衡群集。这个文件不适用于受管域。要使用这个配置,请停止您的服务器并用下列命令重启:EAP_HOME/bin/standalone.sh -c standalone-ha.xml
standalone-full-ha.xml EAP_HOME/standalone/configuration/standalone-full-ha.xml 这是用于独立服务器的配置示例。它包含对每种可能的子系统的支持,包含那些要求高可用性的子系统。要使用它,请停止您的服务器并用下列命令重启:EAP_HOME/bin/standalone.sh -c standalone-full-ha.xml
这些只是默认的位置。您可以在运行时指定不同的配置文件。

2.4.2. 配置文件历史

应用服务器的配置文件包括 standalone.xmldomain.xmlhost.xml。虽然您可以直接编辑这些文件,我们推荐用可用的管理操作(如管理 CLI 或管理控制台)来配置应用服务器模型。
为了协助维护和管理服务器实例,应用服务器在启动时创建了原始配置文件的带时间戳的版本。管理操作导致的任何其他的配置修改都会让原始文件自动备份,而实例的一个工作备份会保留以供引用或回滚。这个归档功能可以扩展为保存、加载和删除服务器配置的快照,从而允许回调和回滚场景。

2.4.3. 用以前的配置启动服务器

下面的例子展示了如何用独立服务器的 standalone.xml 里的以前的配置启动应用服务器。相同的概念也适用于受管域的 domain.xmlhost.xml
这个例子回调了管理操作修改服务器模型时应用服务器自动保存的配置。
  1. 确定您要启动的备份版本。这个例子将回调成功引导后第一次修改前的服务器模型的实例。
    EAP_HOME/configuration/standalone_xml_history/current/standalone.v1.xml 
  2. 传入 jboss.server.config.dir 下的相对文件名,用备份模型的配置启动服务器。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml 
结果

应用服务器用所选的配置启动了。

2.4.4. 使用管理 CLI 保存配置快照

总结

配置快照是当前服务器配置的时间点拷贝。管理员可以保存和加载这些拷贝。

下面的例子使用了 standalone.xml 配置文件,但相同的过程适用于 domain.xmlhost.xml 配置文件。

过程 2.7. 创建配置快照并保存

  • 保存快照

    运行 take-snapshot 操作来创建当前服务器配置的快照。
    [standalone@localhost:9999 /] :take-snapshot
    {
        "outcome" => "success",
        "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
    
结果

保存了当前服务器配置的快照。

2.4.5. 使用管理 CLI 加载配置快照

配置快照是当前服务器配置的时间点拷贝。管理员可以保存和加载这些拷贝。加载快照的过程和用于 第 2.4.3 节 “用以前的配置启动服务器” 的方法类似,都是从命令行而不是管理 CLI 界面运行来创建、列出和删除快照。
下面的例子使用了 standalone.xml 配置文件,但相同的过程适用于 domain.xmlhost.xml 配置文件。

过程 2.8. 加载配置快照

  1. 确定要加载的快照。这个例子将从 snapshot 目录回调下列文件。下面是快照文件的默认路径。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml
    快照是用相对路径表达的,上面的例子可以像下面这样编写。
    jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml
  2. 通过传入文件名用所选的配置快照启动服务器。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml
结果

服务器用加载快照里选择的配置进行了重启。

2.4.6. 使用管理 CLI 删除配置快照

配置快照是当前服务器配置的时间点拷贝。管理员可以保存和加载这些拷贝。
下面的例子使用了 standalone.xml 配置文件,但相同的过程适用于 domain.xmlhost.xml 配置文件。

过程 2.9. 删除专有的快照

  1. 确定要删除的快照。这个例子将从 snapshot 目录删除下列文件。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml
  2. 如下例所示,指定快照的名称,运行 :delete-snapshot 命令来删除专有的快照。
    [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
    {"outcome" => "success"}
    
结果

快照已被删除。

过程 2.10. 删除所有快照

  • 如下例所示,运行 :delete-snapshot(name="all") 命令删除所有的快照。
    [standalone@localhost:9999 /] :delete-snapshot(name="all")
    {"outcome" => "success"}
    
结果

所有快照都已被删除。

2.4.7. 使用管理 CLI 列出所有的配置快照

配置快照是当前服务器配置的时间点拷贝。管理员可以保存和加载这些拷贝。
下面的例子使用了 standalone.xml 配置文件,但相同的过程适用于 domain.xmlhost.xml 配置文件。

过程 2.11. 列出所有的配置快照

  • 列出所有快照

    :list-snapshots 命令列出所有保存的快照。
    [standalone@localhost:9999 /] :list-snapshots
    {
        "outcome" => "success",
        "result" => {
            "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
            "names" => [
                "20110818-133719699standalone.xml",
                "20110809-141225039standalone.xml",
                "20110802-152010683standalone.xml",
                "20110808-161118457standalone.xml",
                "20110912-151949212standalone.xml",
                "20110804-162951670standalone.xml"
            ]
        }
    }
    
结果

快照被列出。

第 3 章 管理接口

3.1. 管理应用服务器

JBoss EAP 6 提供了多个管理工具来配置和管理你的实现。其中包括新的管理控制台和管理命令行界面(CLI),以及让专家用户可以开发自己的工具的底层管理 API。

3.2. 管理应用程序编程接口(API)

管理客户

JBoss EAP 6 提供了不同的方法来配置和管理服务器,您可以使用 web 界面、命令行客户或一系列的 XML 配置文件。我们推荐的方法是编辑配置文件,包括管理控制台和管理 CLI。对配置文件的编辑总会在不同视图里同步并最终持久化到 XML 文件里。请注意,在服务器实例运行时对 XML 配置文件的修改将被服务器模型所覆盖。

HTTP API

管理控制台是用 Google Web Toolkit (GWT) 构建的 Web 界面的例子。管理控制台和服务器通过 HTTP 管理接口进行通讯。HTTP API 端点是依赖于 HTTP 协议来集成管理层的管理客户的入口点。它使用 JSON 编码协议和 de-typed RPC 风格的 API 来描述和执行管理操作。 HTTP API 用于 Web 控制台,它也为许多其他客户提供了集成能力。

HTTP API 端点和主机控制器或独立服务器是共存的。HTTP API 端点服务两种不同的上下文,一个用于执行管理操作,令为一个用于访问 Web 界面。在默认情况下,它运行在端口 9990 上。

例 3.1. HTTP API 配置文件示例

<management-interfaces>
  [...]
  <http-interface security-realm="ManagementRealm">
     <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>
Web 控制台是通过和 HTTP 管理 API 相同的端口来访问的。区别作为默认的本地主机访问的管理控制台、通过专门主机和端口远程访问的管理控制台和开放的域 API 是很重要的。

表 3.1. 访问管理控制台的 URL

URL 描述
http://localhost:9990/console 访问本地主机的管理控制台,它控制受管域的配置。
http://hostname:9990/console 远程访问管理控制台的主机命名和受管域配置。
http://hostname:9990/management 和管理控制台运行在相同端口上的 HTTP 管理 API,它显示原始属性和开放给 API 的值。
Native API

管理 CLI 就是 Native API 工具的一个例子。这个管理工具可用于受管域及独立服务器,它允许用户连接到域控制器或独立服务器实例并执行 de-typed 管理模型里可用的管理操作。

Native API 端点是依赖于原生协议来集成管理层的管理客户的入口点。它使用开放的二进制协议和基于非常少量的 Java 类型的 RPC 风格的 API 来描述和执行管理操作。它被管理 CLI 工具所使用,但也为很多其他客户提供了集成能力。
Native API 端点和主机控制器或独立服务器是共存的。使用管理 CLI 必须启用它。在默认情况下,它运行在端口 9999 上。

例 3.2. Native API 配置文件示例

<management-interfaces>
  <native-interface security-realm="ManagementRealm">
    <socket-binding native="management-native"/>
  </native-interface>
  [...]
</management-interfaces>

3.3. 关于管理控制台和管理 CLI

在 JBoss EAP 6 里,所有的服务器实例和配置都通过管理界面而不是编辑 XML 文件来进行配置。虽然 XML 配置文件仍可进行编辑,通过管理界面的管理提供了额外校验和服务器实例持久性管理的高级功能。服务器运行时对 XML 配置文件的修改仍会被服务器模型覆盖,任何添加的 XML 注释都会被删除。当服务器实例在运行时,我们应该只使用管理界面来修改配置文件。
要通过 Web 浏览器里的图形化用户界面来管理服务器,请使用管理控制台。
要通过命令行界面来管理服务器,则请使用管理 CLI。

3.4. 管理控制台

3.4.1. 管理控制台

管理控制台是用于 JBoss EAP 6 的基于 Web 的管理工具。
您可以使用管理控制台来启动和停止服务器、部署和卸载应用程序、调整系统设置并对服务器配置进行持久性修改。管理控制台也可以执行管理任务,并在修改需要服务器实例重启或重载时进行实时通知。
在受管域里,相同域里的服务器实例和服务器组可以通过域控制器的管理控制台进行集中管理。

3.4.2. 登录到管理控制台

前提条件

  • JBoss EAP 6 服务器必须正在运行。

过程 3.1. 登录到管理控制台

  1. 进入管理控制台开始页面

    通过 Web 浏览器进入管理控制台。默认的位置是 http://localhost:9990/console/,其中的 9990 是预定义为管理控制台的套接绑定的。
  2. 登录到管理控制台

    输入您之前创建的帐号的用户名和密码来登录到管理控制台屏幕。
    管理控制台的登录屏幕

    图 3.1. 管理控制台的登录屏幕

结果

登录后,下面的管理控制台登录页面将出现:
受管域
独立服务器

3.4.3. 修改管理控制台的语言

基于 Web 的管理控制台默认使用英语,但您可以选择下列语言。

所支持的语言

  • 德语 (de)
  • 简体中文 (zh-Hans)
  • 巴西葡萄牙语 (pt-BR)
  • 法语 (fr)
  • 西班牙语 (es)
  • 日语 (ja)

过程 3.2. 修改基于 Web 的管理控制台的语言

  1. 登录到管理控制台。

    登录到基于 Web 的管理控制台。
  2. 打开 Setting 对话框。

    屏幕的右下角是 Settings 标签。点击它打开管理控制台的设置对话框。
  3. 选择语言。

    Locale 选择框里选择语言。然点选择 Save。确认框通知您需要重载应用程序。点击 Confirm。刷新 Web 浏览器以使用新的区域设置。

3.4.4. 使用管理控制台配置服务器

过程 3.3. 配置服务器

  1. 进入管理控制台里的 Server Configurations 面板。

    1. 从控制台的顶部选择 Hosts 标签页。可用的服务器将显示在表格里。
  2. 编辑服务器配置

    1. Available Server Configurations 表格里选择服务器实例。
    2. 在所选的服务器下方选择 Edit 按钮。
    3. 修改配置属性。
    4. 在服务器列表下方选择 Save 按钮。
结果

服务器配置被修改,且会在服务器重启时生效。

3.4.5. 在管理控制台里添加部署

过程 3.4. 添加和验证部署

  1. 进入管理控制台的 Manage Deployments 面板

    1. 选择控制台顶部的 Runtime 标签页。
    2. 对于独立服务器,展开控制台左侧的 Server 菜单项并选择Manage Deployments。对于受管域,展开控制台左侧的 Domain 菜单项并选择 Manage Deployments
    Manage Deployments 面板将会出现。
  2. 添加部署内容

    点击 Content Repository 标签页上的 Add 按钮。Create Deployment 对话框将会出现。
  3. 选择要部署的文件

    在这个对话框里,点击 Browse 按钮。选择您要部署的文件。选好文件后点击 Next 按钮进行。
  4. 验证部署名

    验证出现在 Create Deployments 对话框里的部署名和 runtime 名称。验证名称后请点击 Save 按钮上传文件。
结果

所选的内容被上传至服务器且可以进行部署了。

3.4.6. 在管理控制台里创建新的服务器

过程 3.5. 创建新的服务器配置

  1. 进入管理控制台里的 Server Configurations 页面

    从控制台的右上角选择 Server 标签页。
  2. 创建新的配置

    1. 点击 Server Configuration 面板顶部的 Add 按钮。
    2. 编辑 Create Server Configuration 对话框里的基本服务器设置。
    3. 点击 保存 按钮保存新的服务器配置。
结果

新服务器被创建且出现在 Server Configurations 列表里。

3.4.7. 用管理控制台修改默认的日志级别

过程 3.6. 编辑日志级别

  1. 进入管理控制台的 Logging 面板

    1. 对于受管域,选择控制台顶部的 Profiles 标签页,然后从控制台左侧的下拉菜单里选择相关的配置集。
    2. 对于受管域或独立服务器,展开控制台左侧菜单的 CoreLogging 菜单并点击 Logging 条目。
    3. 点击控制台顶部的 Log Categories 标签页。
  2. 编辑 logger 细节

    编辑 Log Categories 表格里条目的细节。
    1. Log Categories 表格里选择条目,然后点击下面的 Details 部分里的 Edit 按钮。
    2. 通过 Log Level 下拉框选择类别的日志级别。完成后点击 Save 按钮。
结果

相关类别的日志级别已被更新。

3.4.8. 在管理控制台里创建新的服务器组

过程 3.7. 配置和添加新的服务器组

  1. 进入 Server Groups 视图

    选择右上角的 Hosts 标签页。
  2. 选择左侧的 Server 菜单的 Server Groups 标签页。
  3. 添加服务器组

    点击 Add 按钮来添加新的服务器组。
  4. 配置服务器组

    1. 输入服务器组的名称。
    2. 选择您添加服务器组的配置集。
    3. 选择您添加服务器组的套接字绑定。
    4. 点击 Save 按钮来保存新的组。
结果

新创建的服务器组出现在管理控制台里了。

3.5. 管理 CLI

3.5.1. 关于管理命令行接口(Command Line Interface,CLI)

管理 CLI 是 JBoss EAP 6 的一个命令行管理工具。
使用管理 CLI 启动和停止服务器、部署和卸载应用程序、配置系统设置并执行其他管理任务。操作可以批量模式进行,将多个任务作为一个组来运行。

3.5.2. 启动管理 CLI

过程 3.8. 在 Linux 或 Windows 里启动 CLI

    • 在 Linux 里启动 CLI

      运行 EAP_HOME/bin/jboss-cli.sh 命令:
      $ EAP_HOME/bin/jboss-cli.sh
    • 在 Windows 里启动 CLI

      运行 EAP_HOME\bin\jboss-cli.bat 命令:
      C:\>EAP_HOME\bin\jboss-cli.bat

3.5.3. 退出管理 CLI

过程 3.9. 退出管理 CLI

  • 运行 quit 命令

    在管理 CLI 里,输入 quit 命令:
    [domain@localhost:9999 /] quit
    Closed connection to localhost:9999

3.5.4. 用管理 CLI 连接受管服务器实例

过程 3.10. 连接至受管服务器实例

  • 运行 connect 命令

    在管理 CLI 里,输入 connect 命令:
    [disconnected /] connect
    Connected to domain controller at localhost:9999
    • 或者,在 Linux 系统里启动管理 CLI 时使用 --connect 参数来连接至受管服务器:
      $ EAP_HOME/bin/jboss-cli.sh --connect
    • --connect 参数可以用来指定服务器的主机和端口。要连接至地址 192.168.0.1 和端口 9999,请使用下列命令:
      $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999

3.5.5. 用管理 CLI 获取帮助

概述

管理 CLI 有带有普通和上下文敏感选项的帮助对话框。对于独立服务器和域控制器,依赖于操作上下文的 help 命令都要求已建立的连接。除非连接已建立,否则这些命令不会出现在列表里。

过程 3.11. 普通和上下文敏感帮助

  1. 运行 help 命令

    在管理 CLI 里,输入 help 命令:
    [standalone@localhost:9999 /] help
  2. 获取上下文敏感帮助

    在管理 CLI 里,输入 help -commands 扩展命令:
    [standalone@localhost:9999 /] help --commands
  3. 关于特定命令的更多详情,请运行 help 并以 '--help' 为参数。
    [standalone@localhost:9999 /]  deploy --help
结果

CLI 帮助信息被显示。

3.5.6. 以批模式使用管理 CLI

概述

批处理允许大量的操作请求按序列进行分组,然后作为一个单元来执行。如果序列里的任何以一个操作请求执行失败,整个操作组都将回滚。

过程 3.12. 批处理模式命令和操作

  1. 启用批处理模式

    batch 命令启用批处理模式。
    [standalone@localhost:9999 /] batch
    [standalone@localhost:9999 / #]
    提示里的井号(#)指明了批处理模式
  2. 添加操作请求到批处理命令里

    在批处理模式下,照常输入操作请求。操作请求将按输入的顺序添加到批处理命令里。
    关于格式化操作请求的详情,请参考 第 3.5.8 节 “在管理 CLI 里使用操作和命令”
  3. 运行批处理命令

    一旦输入了整个操作请求序列,请用 run-batch 运行这个批处理命令。
    [standalone@localhost:9999 / #] run-batch
    The batch executed successfully.
    关于可用于批处理的完整的命令列表,请参考 第 3.5.7 节 “CLI 批处理模式命令”
  4. 保存在外部文件里的批命令

    频繁运行的批处理命令可以存储在外部文件里,通过将完整文件路径作为参数传入 batch 或直接作为 run-batch 命令的参数来执行。
    您可以用文本编辑器创建批处理命令文件。每个命令都必须单独一行且 CLI 应该可以访问它。
    下面的命令将加载 myscript.txt 文件至批处理模式。这个文件里的所有命令都可以编辑或删除,您也可以插入新的命令。这个批处理会话里进行的修改不会持久化到 myscript.txt 文件里。
    [standalone@localhost:9999 /] batch --file=myscript.txt
    下面的命令将立即运行存储在文件 myscript.txt 里的批命令
    [standalone@localhost:9999 /] run-batch --file=myscript.txt
结果

输入的操作请求序列以批模式完成了。

3.5.7. CLI 批处理模式命令

这个表提供了 JBoss EAP 6 CLI 里可用的批处理命令列表。这些命令只能用于批处理模式。

表 3.2. CLI 批处理模式命令

命令名 描述
list-batch 当前批次里的命令和操作的列表。
edit-batch-line line-number edited-command 通过行号和要编辑的命令来编辑当前批处理里的行。例如: edit-batch-line 2 data-source disable --name=ExampleDS
move-batch-line fromline toline 指定您要移动的行号为第一个参数且新的位置为第二个参数来重新对批处理命令里的行进行排序。例如: move-batch-line 3 1
remove-batch-line linenumber 删除指定行上的批处理命令。例如: remove-batch-line 3
holdback-batch [batchname]
如果您突然想在 CLI 里执行批处理之外的命令,您可以使用这个命令推迟或存储当前的批处理命令。要返回已暂停批模式,只要在 CLI 命令行上再次输入 batch 就可以了。
如果在 holdback-batch 命令时您提供了 batchname,批命令将按照这个名称进行存储要返回命名的批次,请使用 batch batchname。不使用 batchname 调用 batch 命令将启动新的(未命名)的批处理。系统里只能有一个未命名的暂停批命令。
要查看暂停批命令的列表,请使用 batch -l 命令。
discard-batch 取消当前活动的批处理命令。

3.5.8. 在管理 CLI 里使用操作和命令

过程 3.13. 创建、配置和执行请求

  1. 构造操作请求

    操作请求允许和管理模型的低层交互。它们提供一种可控的方式来编辑服务器配置。操作请求由三部分组成:
    • 地址,前缀为斜杠(/)。
    • 操作名称,前缀为分号(:)。
    • 可选的参数,包含在括号(())里。
    1. 确定地址

      配置以有地址的资源层级树型出现。每个资源节点都提供了一系列不同的操作。地址指定哪些资源可以执行操作。地址使用下面的语法:
      /node-type=node-name
      • node-type 是资源节点的类型。它映射配置 XML 文件里的元素名称。
      • node-name 是资源节点的名称。它映射配置 XML 文件里的元素的 name 属性。
      • 用斜杠(/)分隔资源树的每个级别。
      要确定所需的地址,请参考 XML 配置文件。EAP_HOME/standalone/configuration/standalone.xml 文件保存独立服务器的配置信息,EAP_HOME/domain/configuration/domain.xmlEAP_HOME/domain/configuration/host.xml 文件保存受管域的配置信息。

      例 3.3. 操作地址示例

      要执行 Logging 子系统上的操作,请使用操作请求里的下列地址:
      /subsystem=logging
      要执行 Java 数据源上的操作,请使用操作请求里的下列地址:
      /subsystem=datasources/data-source=java
    2. 确定操作

      对于不同类型的资源节点,操作会有所不同。操作使用下面的语法:
      :operation-name
      • operation-name 是要请求的操作的名称。
      在独立服务器上的任何资源地址上使用 read-operation-names 操作来列出可用的操作。

      例 3.4. 可用的操作

      要列出 Logging 子系统到所有可用的操作,在独立服务器里输入下列请求:
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove",
              "undefine-attribute",
              "whoami",
              "write-attribute"
          ]
      }
      
    3. 确定任何参数

      每个操作可能需要不同的参数。
      参数使用下面的语法:
      (parameter-name=parameter-value)
      • parameter-name 是参数的名称。
      • parameter-value 是参数的值。
      • 多个参数用逗号隔开(,)。
      要确定所需的参数,在资源节点上执行 read-operation-description 命令,将操作名称作为参数传入。详情请参考 例 3.5 “确定操作的参数”

      例 3.5. 确定操作的参数

      要确定 logging 子系统上的 read-children-types 操作的必需参数,请输入 read-operation-description 命令:
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "read-children-types",
              "description" => "Gets the type names of all the children under the selected resource",
              "reply-properties" => {
                  "type" => LIST,
                  "description" => "The children types",
                  "value-type" => STRING
              },
              "read-only" => true
          }
      }
      
  2. 输入完整的操作请求

    一旦确定了地址、操作和所有参数,请输入完整的操作请求。

    例 3.6. 操作请求示例

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
结果

管理接口执行服务器配置里的操作请求。

3.5.9. 管理 CLI 命令参考

总结

第 3.5.5 节 “用管理 CLI 获取帮助” 描述了如何访问管理 CLI 的帮助功能,包括有带有普通和上下文敏感选项的帮助对话框。对于独立服务器和域控制器,依赖于操作上下文的 help 命令都要求已建立的连接。除非连接已建立,否则这些命令不会出现在列表里。

表 3.3. 

命令 描述
batch 通过创建新的批次、或者重新激活现有的暂停的批次来启动批模式。如果没有暂停的批命令,这个命令将启动新的批次。如果存在未命名的暂停的批命令,这个命令将重新激活它。如果存在有名称的暂停的批命令,将这个批次的名称作为参数来执行命令就可以激活。
cd 根据参数修改当前的节点路径。当前的节点路径用于不包含地址部分的操作请求的地址。如某个操作请求包含了地址,所包含的地址将当作当前节点路径的相对地址。当前的节点路径可以以节点类型结尾。此时,执行指定节点名称的操作就足够了,例如 logging:read-resource。
clear 清除屏幕。
command 允许您添加、删除和列出现有的普通类型的命令。普通类型命令是分配专有节点类型的命令,它允许您执行该类型的实例的任何可用的操作。它也可以修改现有实例上类型开放的任何属性。
connect 连接到指定主机和端口上的控制器。
connection-factory 定义连接工厂。
data-source 管理 datasource 子系统里的 JDBC 数据源配置。
deploy 部署用文件路径指定的应用程序或启用资料库里现有的被禁用的应用程序。如果不带参数执行,这个命令将列出全部现有的部署。
help 显示帮助信息。它可以用 --commands 参数为给定命令提供上下文敏感的内容。
history 显示内存里的 CLI 命令历史以及启用/禁用历史扩展的状态。它可以按需要用参数来清除、禁用和启用历史扩展。
jms-queue 在 messaging 子系统里定义一个 JMS 队列。
jms-topic 在 messaging 子系统里定义一个 JMS 主题。
ls 列出节点路径的内容。在默认情况下,终端窗口会用整屏以列显示结果。-l 参数将以每行一个名字显示结果。
pwd 显示当前工作节点的完整节点路径。
quit 终止命令行界面。
read-attribute 根据参数显示受管资源属性的值和描述。
read-operation 显示指定操作的描述,未指定则列出所有的操作。
undeploy 以应用程序的名称为参数运行可以卸载应用程序。它也可以通过参数运行从资料库删除应用程序。如无参数运行则输出所有现有的部署。
version 显示应用服务器版本和环境信息。
xa-data-source 管理 datasource 子系统里的 JDBC XA 数据源配置。

3.5.10. 管理 CLI 操作参考

开放管理 CLI 里的操作

管理 CLI 里的操作可以用 第 3.6.5 节 “用管理 CLI 显示操作名称” 里描述的 read-operation-names 操作开放。这些操作描述可以用 第 3.6.4 节 “用管理 CLI 显示操作描述” 里描述的 read-operation-descriptions 操作来开放。

表 3.4. 管理 CLI 操作

操作名称 描述
add-namespace 在 namespaces 属性的表里添加命名空间前缀映射。
add-schema-location 在 schema-locations 属性的表里添加模式位置 映射。
delete-snapshot 从 snapshots 目录删除服务器配置的快照。
full-replace-deployment 添加之前上传的部署内容到可用内容列表里,替换 runtime 里具有相同名称的现有内容,并从可用列表里删除替换的内容。进一步的信息请点击链接。
list-snapshots 列出保存在 snapshots 目录里的服务器配置的快照。
read-attribute 显示所选资源的属性的值。
read-children-names 显示给定类型的资源下的所有子资源的名称。
read-children-resources 显示给定类型的资源的所有子资源的信息。
read-children-types 显示所选资源下的所有子资源的类型名称。
read-config-as-xml 读取当前的配置并以 XML 格式显示。
read-operation-description 显示给定资源上的操作的细节。
read-operation-names 显示给定资源上的所有操作的名称。
read-resource 显示模型资源的属性值以及任何子资源的基本或完整的信息。
read-resource-description 显示资源属性的描述、子资源和操作的类型。
reload 关闭所有服务并重启来重载服务器。
remove-namespace 在 namespaces 属性的表里删除命名空间前缀映射。
remove-schema-location 在 schema-locations 属性的表里删除模式位置 映射。
replace-deployment 用新的内容替换 runtime 里的内容。新的内容必须已经上传到部署的内容资料库。
resolve-expression 接受表达式或可以解析为表达式的字符串的操作,并根据本地系统属性和环境变量进行解析。
resolve-internet-address 通过一系列接口解析标准找到本地主机上的 IP 地址,如果没有匹配的 IP 地址则运行失败。
server-set-restart-required 让服务器进入需要重启的模式
shutdown 通过调用 System.exit(0) 关闭服务器。
start-servers 启动受管域里配置的且当前没有运行的所有服务器。
stop-servers 停止当前运行在受管域里的所有服务器。
take-snapshot 创建服务器配置的快照并保存在 snapshots 目录。
upload-deployment-bytes 指定所包含的字节队列上的部署内容应该添加到部署内容资料库。请注意,这个操作没有指明内容应该部署至 runtime。
upload-deployment-stream 指定所包含的输入流索引上可用的部署内容应该添加到部署内容资料库。请注意,这个操作没有指明内容应该部署到 runtime。
upload-deployment-url 指定所包含的 URL 上可用的部署内容应该添加到部署内容资料库。请注意,这个操作没有指明内容应该部署至 runtime。
validate-address 检验操作的地址。
write-attribute 设置所选资源的属性的值。

3.6. 管理 CLI 操作

3.6.1. 用管理 CLI 显示资源属性

总结

read-attribute 操作是一个用来读取选定属性的当前 runtime 值的全局操作。它可以用来只开放用户设置的值而忽略任何默认或未定义的值。请求属性包括下列参数。

请求属性

name
获取所选资源下的值的属性的名称。
include-defaults
布尔型参数,可以设置为 false 来限制操作结果,只显示用户设置的属性并忽略默认的值。

过程 3.14. 显示所选属性的当前 Runtime 值

read-attribute 操作的优势是开放专有属性的当前 runtime 值的能力。用 read-resource 操作可获得类似的结果,但只能通过 include-runtime 请求属性,而且只作为该节点的所有可用资源的列表的一部分。read-attribute 操作用于细颗粒度的属性查询,如下例所示。

例 3.7. 运行 read-attribute 操作来开放公共的接口 IP。

如果您知道要开放的属性的名称,您可以使用 read-attribute 来获取当前 runtime 里的确切的值。
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}

resolved-address 属性是一个 runtime 值,所以不会显示在标准的 read-resource 操作的结果里。
[standalone@localhost:9999 /] /interface=public:read-resource                        
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}

要显示 resolved-address 和其他 runtime 值,您必须使用 include-runtime 请求属性。
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "resolved-address" => "127.0.0.1",
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}

结果

显示当前的 runtime 属性值。

3.6.2. 在管理 CLI 里显示活动用户

总结

whoami 操作是用于确定当前活动用户的全局操作。这个操作开放了用户名标识及它们分配的区。管理员可以用 whoami 操作来管理多个区上的多个用户帐号,或者跟踪具有多个终端会话和用户帐号的域实例上的活动用户。

过程 3.15. 在管理 CLI 里用 whoami 操作显示活动用户

  • 运行 whoami 操作

    在管理 CLI 里,请用 whoami 操作来显示活动的用户帐号。
    [standalone@localhost:9999 /] :whoami
    下面的例子使用了独立服务器实例里的 whoami 操作来显示活动用户 username,以及它所分配的 ManagementRealm 区。

    例 3.8. 在独立实例里使用 whoami

    [standalone@localhost:9999 /]:whoami
    {
        "outcome" => "success",
        "result" => {"identity" => {
            "username" => "username",
            "realm" => "ManagementRealm"
        }}
    }
    
    
结果

显示当前的活动用户帐号。

3.6.3. 在管理 CLI 里显示系统和服务器信息

过程 3.16. 在管理 CLI 里显示系统和服务器信息

  • 运行 version 命令

    在管理 CLI 里,输入 version 命令:
    [domain@localhost:9999 /] version
结果

显示应用服务器版本和环境信息。

3.6.4. 用管理 CLI 显示操作描述

过程 3.17. 在管理 CLI 里执行命令

  • 运行 read-operation-description 操作

    在管理 CLI 里,使用 read-operation-description 来显示操作信息。这个操作要求键-值格式的其他参数以指定要显示的操作。关于操作请求的详情,请参考 第 3.5.8 节 “在管理 CLI 里使用操作和命令”
    [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

例 3.9. 显示 list-snapshots 操作的描述

下面的例子显示了描述 list-snapshots 操作的方法。
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "list-snapshots",
        "description" => "Lists the snapshots",
        "request-properties" => {},
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "min-length" => 1L,
                    "max-length" => 2147483647L
                },
                "names" => {
                    "type" => LIST,
                    "description" => "The names of the snapshots within the snapshots directory",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "value-type" => STRING
                }
            }
        },
        "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}},
        "read-only" => false
    }
}
结果

显示所选操作的描述。

3.6.5. 用管理 CLI 显示操作名称

过程 3.18. 在管理 CLI 里执行命令

例 3.10. 用管理 CLI 显示操作名称

下面的例子显示了描述 read-operation-names 操作的方法。
[standalone@localhost:9999 /]:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "resolve-expression",
        "resolve-internet-address",
        "server-set-restart-required",
        "shutdown",
        "take-snapshot",
        "undefine-attribute",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "validate-operation",
        "whoami",
        "write-attribute"
    ]
}
结果

显示可用的操作名称。

3.6.6. 用管理 CLI 显示可用资源

总结

read-resource 操作是用来读取资源值的全局操作。它可以用来开放当前节点或子节点额资源的基本或完整的信息,以及扩展或限制操作结果的作用域的请求属性。请求属性包含下列参数。

请求属性

recursive
是否递归地包含子资源的完整信息。
recursive-depth
应该包含子节点资源信息的深度。
proxies
是否在递归查询里包含远程资源。例如,包含域控制器查询里从主机控制器的主机级别资源。
include-runtime
是否在响应里包含 runtime 属性,如不是来自持久性配置的属性值。这个请求属性默认是 false。
include-defaults
这是一个 boolean 型的请求属性,它启用或禁用默认属性的读取。当设置为 false 时,只返回用户设置的属性,忽略了那些未定义的属性。

过程 3.19. 在管理 CLI 里执行命令

  1. 运行 read-resource 操作

    在管理 CLI 里,请用 read-resource 操作来显示可用的资源。
    [standalone@localhost:9999 /]:read-resource
    下面的例子展示了在独立服务器里如何使用 read-resource 操作来开放普通资源信息。结果类似于 standalone.xml 配置文件,显示系统资源、扩展、接口和为服务器实例安装和配置的子系统。它们可以进一步进行直接查询。

    例 3.11. 在根级别使用 read-resource 操作

    [standalone@localhost:9999 /]:read-resource
    {
        "outcome" => "success",
        "result" => {
            "deployment" => undefined,
            "deployment-overlay" => undefined,
            "management-major-version" => 1,
            "management-micro-version" => 0,
            "management-minor-version" => 4,
            "name" => "longgrass",
            "namespaces" => [],
            "product-name" => "EAP",
            "product-version" => "6.1.0.GA",
            "release-codename" => "Janus",
            "release-version" => "7.2.0.Final-redhat-3",
            "schema-locations" => [],
            "system-property" => undefined,
            "core-service" => {
                "management" => undefined,
                "service-container" => undefined,
                "server-environment" => undefined,
                "platform-mbean" => undefined
            },
            "extension" => {
                "org.jboss.as.clustering.infinispan" => undefined,
                "org.jboss.as.connector" => undefined,
                "org.jboss.as.deployment-scanner" => undefined,
                "org.jboss.as.ee" => undefined,
                "org.jboss.as.ejb3" => undefined,
                "org.jboss.as.jaxrs" => undefined,
                "org.jboss.as.jdr" => undefined,
                "org.jboss.as.jmx" => undefined,
                "org.jboss.as.jpa" => undefined,
                "org.jboss.as.jsf" => undefined,
                "org.jboss.as.logging" => undefined,
                "org.jboss.as.mail" => undefined,
                "org.jboss.as.naming" => undefined,
                "org.jboss.as.pojo" => undefined,
                "org.jboss.as.remoting" => undefined,
                "org.jboss.as.sar" => undefined,
                "org.jboss.as.security" => undefined,
                "org.jboss.as.threads" => undefined,
                "org.jboss.as.transactions" => undefined,
                "org.jboss.as.web" => undefined,
                "org.jboss.as.webservices" => undefined,
                "org.jboss.as.weld" => undefined
            },
            "interface" => {
                "management" => undefined,
                "public" => undefined,
                "unsecure" => undefined
            },
            "path" => {
                "jboss.server.temp.dir" => undefined,
                "user.home" => undefined,
                "jboss.server.base.dir" => undefined,
                "java.home" => undefined,
                "user.dir" => undefined,
                "jboss.server.data.dir" => undefined,
                "jboss.home.dir" => undefined,
                "jboss.server.log.dir" => undefined,
                "jboss.server.config.dir" => undefined,
                "jboss.controller.temp.dir" => undefined
            },
            "socket-binding-group" => {"standard-sockets" => undefined},
            "subsystem" => {
                "logging" => undefined,
                "datasources" => undefined,
                "deployment-scanner" => undefined,
                "ee" => undefined,
                "ejb3" => undefined,
                "infinispan" => undefined,
                "jaxrs" => undefined,
                "jca" => undefined,
                "jdr" => undefined,
                "jmx" => undefined,
                "jpa" => undefined,
                "jsf" => undefined,
                "mail" => undefined,
                "naming" => undefined,
                "pojo" => undefined,
                "remoting" => undefined,
                "resource-adapters" => undefined,
                "sar" => undefined,
                "security" => undefined,
                "threads" => undefined,
                "transactions" => undefined,
                "web" => undefined,
                "webservices" => undefined,
                "weld" => undefined
            }
        }
    }
    
    
  2. 针对子节点运行 read-resource 操作

    read-resource 操作可以查询根节点的子节点。操作的结构首先定义要开放的节点,然后附加这个操作来运行。
    [standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource
    在下面的例子里,通过指引 read-resource 操作到专有的 Web 子系统节点来开放 Web 子系统组件的专有资源信息。

    例 3.12. 开放根结点的子节点资源

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    
    相同的结果可以用 cd 命令进入子节点并直接运行 read-resource 操作获得。

    例 3.13. 通过修改目录开放子节点资源

    [standalone@localhost:9999 /] cd subsystem=web
    
    [standalone@localhost:9999 subsystem=web] cd connector=http
    
    [standalone@localhost:9999 connector=http] :read-resource
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    
  3. 使用 recursive 参数在结果里包含活动的属性值。

    recursive 参数可以用来开放所有属性的值,包括非持久性的值、在启动时传入的值或其他在 runtime 模型里活动的属性。
    [standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)
    和之前的例子相比, include-runtime 请求属性会开放其他的活动属性,如发送的字节和 HTTP 连接器接收的字节。

    例 3.14. 用 include-runtime 参数开放其他活动的属性值。

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
    {
        "outcome" => "success",
        "result" => {
            "any" => undefined,
            "any-address" => undefined,
            "any-ipv4-address" => undefined,
            "any-ipv6-address" => undefined,
            "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
            "link-local-address" => undefined,
            "loopback" => undefined,
            "loopback-address" => undefined,
            "multicast" => undefined,
            "name" => "public",
            "nic" => undefined,
            "nic-match" => undefined,
            "not" => undefined,
            "point-to-point" => undefined,
            "public-address" => undefined,
            "resolved-address" => "127.0.0.1",
            "site-local-address" => undefined,
            "subnet-match" => undefined,
            "up" => undefined,
            "virtual" => undefined
        }
    }
    
    

3.6.7. 用管理 CLI 显示可用资源的描述

过程 3.20. 在管理 CLI 里执行命令

  1. 运行 read-resource-description 操作

    在管理 CLI 里,使用 read-resource-description 来读取和显示可用资源。关于操作请求的详情,请参考 第 3.5.8 节 “在管理 CLI 里使用操作和命令”
    [standalone@localhost:9999 /]:read-resource-description
  2. 使用可选参数

    read-resource-description 操作允许使用其他参数。
    1. 使用 operations 参数来包含资源操作的描述。
      [standalone@localhost:9999 /]:read-resource-description(operations=true)
    2. 使用 inherited 参数可以包含或排除资源继承操作的描述。默认状态是 true。
      [standalone@localhost:9999 /]:read-resource-description(inherited=false)
    3. 使用 recursive 参数来包含子资源的递归描述。
      [standalone@localhost:9999 /]:read-resource-description(recursive=true)
    4. 使用 locale 参数来获取资源描述。如果为 null 则使用默认的 locale。
      [standalone@localhost:9999 /]:read-resource-description(locale=true)
结果

显示可用资源的描述。

3.6.8. 用管理 CLI 重载应用服务器

过程 3.21. 重载应用服务器

结果

关闭所有服务且再次启动 runtime 来完成服务器重载。管理 CLI 将自动重新连接。

3.6.9. 用管理 CLI 关闭应用服务器

过程 3.22. 关闭应用服务器

  • 运行 shutdown 操作

    • 在管理 CLI 里,使用 shutdown 操作通过 System.exit(0) 系统调用来关闭服务器。关于操作请求的详情,请参考 第 3.5.8 节 “在管理 CLI 里使用操作和命令”
      • 在独立模式下,请使用下列命令:
        [standalone@localhost:9999 /]:shutdown
      • 在域模式下,请使用下列命令及合适的主机名:
        [domain@localhost:9999 /]/host=master:shutdown
    • 要连接到附加的 CLI 实例并关闭服务器,请执行下列命令:
      jboss-cli.sh --connect command=:shutdown
      
    • 要连接到远程的 CLI 实例并关闭服务器,请执行下列命令:
      [disconnected /] connect IP_ADDRESS
      Connected to IP_ADDRESS:PORT_NUMBER
      [192.168.1.10:9999 /] :shutdown
      
      用实例的 IP 地址替换 IP_ADDRESS
结果

服务器被关闭。管理 CLI 将断开连接,因为 runtime 已是不可用的。

3.6.10. 使用管理 CLI 配置属性

总结

write-attribute 操作是用来写入或修改资源属性的全局操作。您可以使用这个操作来进行持久性修改并修改管理的服务器实例的配置设置。请求属性包含下列参数。

请求属性

name
需要设置值的所选资源属性的名称。
value
所选资源里属性的值。如果底层模型支持 null 值的话可以为 null。

过程 3.23. 使用管理 CLI 配置资源属性

  • 运行 write-attribute 操作

    在管理 CLI 里,使用 write-attribute 操作修改资源属性的值。这个擦作可以运行在资源的子节点或管理 CLI 的根节点上(指定完整资源路径)。

例 3.15. 用 write-attribute 操作禁用部署扫描器。

下面的例子使用了 write-attribute 操作来禁用部署扫描器。这个操作从根节点运行,使用 Tab Completion 来协助填充正确的资源路径。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}

操作的结果可以直接用 read-attribute 操作确认。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}

read-resource 操作列出节点的所有可用资源属性可以确认资源。在下列例子里,这个特定的配置展示了 scan-enabled 属性被设置为 false
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource                                 
{
    "outcome" => "success",
    "result" => {
        "auto-deploy-exploded" => false,
        "auto-deploy-xml" => true,
        "auto-deploy-zipped" => true,
        "deployment-timeout" => 600,
        "path" => "deployments",
        "relative-to" => "jboss.server.base.dir",
        "scan-enabled" => false,
        "scan-interval" => 5000
    }
}

结果

更新了资源属性

3.7. 管理 CLI 命令历史

3.7.1. 使用管理 CLI 命令历史

应用服务器安装时会默认启用管理 CLI 的历史命令功能。这个历史记录既在活动的 CLI 会话的易变内存里保持一条记录,也附加内容在自动保存在用户的主目录的 .jboss-cli-history 日志文件上。这个历史记录文件默认是记录最多 500 条 CLI 命令。
history 命令自身将返回当前会话的历史记录,或用其他参数将禁用、启用或清除会话内存里的历史记录。管理 CLI 也可以通过键盘上的箭头来在命令和操作的历史记录里前进或后退。

3.7.2. 显示管理 CLI 命令历史

过程 3.24. 显示管理 CLI 命令历史

  • 运行 history 命令

    在管理 CLI 里,输入 history 命令:
    [standalone@localhost:9999 /] history
结果

在 CLI 启动或历史清除命令显示后保存在内存里的 CLI 命令历史。

3.7.3. 清除管理 CLI 命令历史

过程 3.25. 清除管理 CLI 命令历史

  • 运行 history --clear 命令

    在管理 CLI 里,输入 history --clear 命令:
    [standalone@localhost:9999 /] history --clear
结果

自 CLI 启动后记录的命令历史将从会话内存里删除。这些命令历史仍然保存在用户主目录的 .jboss-cli-history 文件里。

3.7.4. 禁用管理 CLI 命令历史

过程 3.26. 禁用管理 CLI 命令历史

  • 运行 history --disable 命令

    在管理 CLI 里,输入 history --disable 命令:
    [standalone@localhost:9999 /] history --disable
结果

CLI 里执行的命令不会记录在内存里或保存在用户主目录的 .jboss-cli-history 文件里。

3.7.5. 启用管理 CLI 命令历史

过程 3.27. 启用管理 CLI 命令历史

  • 运行 history --enable 命令

    在管理 CLI 里,输入 history --enable 命令:
    [standalone@localhost:9999 /] history --enable
结果

CLI 里执行的命令会记录在内存里并保存在用户主目录的 .jboss-cli-history 文件里。

3.8. 管理接口审计日志

3.8.1. 关于管理接口审计日志

启用审计日志后,通过管理 CLI 执行的操作将在审计日志记录。不管这些操作是否通过管理控制台、管理 CLI 还是自定义的接口执行,都会登记审计日志。日志记录可以输出到文件里或转发到 Syslog 服务器,也可以两者都进行。在默认情况下,审计日志是禁用的。
日志数据以 JSON 格式输出,并有几个配置选项可以影响日志里的操作及日志条目的格式。
在存储日志之前,格式器和处理程序会先处理日志条目。格式器指定日志条目的格式,而处理程序输出记录到指定的目的地。目前只有一个可用的格式器,它以 JSON 格式输出条目。

注意

审计日志只能通过管理 CLI 进行配置。

3.8.2. 从管理 CLI 里启用管理接口的审计日志

要在管理 CLI 启用审计日志,请使用下列命令。
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
审计日志是预配置输出到 EAP_HOME/standalone/data/audit-log.log 里的。

3.8.3. 关于管理接口的审计日志格式器

格式器指定日志条目的格式。

表 3.5. JSON 格式器字段

属性 描述
include-date 布尔值,它定义格式化日志记录是否包含时间戳。
date-separator 包含分隔日期和格式化日志信息的字符的字符串。如果 include-date=false 则被忽略。
date-format 用于时间戳的 java.text.SimpleDateFormat.可以时别的日期格式。如果 include-date=false 则被忽略。
compact 如果为 true,它将在一行里格式化 JSON 信息。因为仍有包含新行符的值,所以如果需要在同一行里容纳整个记录,可以设置 escape-new-lineescape-control-characterstrue
escape-control-characters 如果为 true,它将所有带有八进制 ASCII 字符的控制字符(带有十进制值 < 32 的 ASCII 条目)转义;例如新行将转义为 '#012'。如果它为 true,它将覆盖 escape-new-line=false
escape-new-line 如果为 true 会将所有带有八进制的 ASCII 代码的新行转义,例如 "#012"。

3.8.4. 关于管理接口的审计日志文件处理程序

文件处理程序通过参数来指定哪些日志记录输出到文件里。它还定义格式器、文件名和路径。

表 3.6. 文件处理程序的审计日志字段

属性 描述 只读的
formatter 用来格式化日志记录的 JSON 格式器的名称。 False
path 审计日志文件的路径。 False
relative-to 之前的命名路径的名称,或者系统提供的标准路径中的一个。如果提供了 relative-to,path 属性的值将作为这个属性指定的路径的相对路径对待。 False
failure-count 初始化处理程序前记录日志失败的次数。 True
max-failure-count 禁用这个处理程序前记录日志失败的最多次数。 False
disabled-due-to-failure true 表示如果登记日志失败则禁用处理程序。 True

3.8.5. 关于管理接口的审计日志 Syslog 处理程序

Syslog 处理程序通过参数指定哪些审计日志条目被发送到 Syslog 服务器,特别是 Syslog 服务器侦听的的主机名和端口。
发送审计日志到 Syslog 服务器比本地文件或本地 Syslog 服务器提供了更安全的选项。您可以定义多个 Syslog 处理程序。
Syslog 服务器有不同的实现,所以并非所有设置都可应用到所有的 Syslog 服务器上。我们已用 rsyslog syslog 实现进行了测试。引用的 RFC 是:
  • http://www.ietf.org/rfc/rfc3164.txt
  • http://www.ietf.org/rfc/rfc5424.txt
  • http://www.ietf.org/rfc/rfc6587.txt

表 3.7. Syslog 处理程序字段

字段 描述 只读的值
formatter 用来格式化日志记录的格式器的名称。 False
failure-count 初始化处理程序前记录日志失败的次数。 True
max-failure-count 禁用这个处理程序前记录日志失败的最多次数。 False
disabled-due-to-failure True 表示如果登记日志失败则禁用处理程序。 True
syslog-format Syslog 格式:RFC-5424 或 RFC-3164. False
max-length 日志消息的最大长度(字节),包括头部信息。如果没有定义,syslog-format 为 RFC3164 时它默认为 1024 字节,而 syslog-format 为 RFC5424 时它默认为 2048 字节。 False.
truncate 如果消息长度超过最大字节数,是否要截短(包括头部信息)。如果为 false,消息将即兴分隔然后用相同的头部值来发送。 False

3.8.6. 启用发送到 Syslog 服务器的管理接口审计日志

注意

如果要应用修改到受管域,请添加前缀 /host=HOST_NAME/core-service 命令上。

过程 3.28. 启用发送到 Syslog 服务器的日志

  1. 创建一个名为 msyslog 的 syslog 处理程序

    [standalone@localhost:9999 /]batch
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
    [standalone@localhost:9999 /]run-batch
  2. 在 syslog 处理程序里添加一个引用。

    [standalone@localhost:9999 /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
结果

管理接口的审计日志登记在 syslog 服务器上。

3.8.7. 管理接口的审计日志选项

除了启用和禁用管理接口审计日志,还有其他可用的配置选项。

配置选项

log-boot
如果为 true,引导服务器时的管理操作将记录审计日志。如果为 false 则不会记录日志。默认为 false
log-read-only
如果为 true,所有的操作都将记录审计日志。如果为 false,只有修改了模型的操作会记录日志。默认为 false

3.8.8. 管理接口的审计日志字段

表 3.8. 管理接口的审计日志字段

字段名称 描述
type 它的值如果为 core,表示是一个管理操作;如果为 jmx,表示它来自 JMX 在系统(关于 JMX 子系统的审计日志请参考 JMX 子系统部分)。
r/o 如果操作没有修改管理模型则为 true,否则为 false
booting 如果操作是在引导过程中执行的则为 true,如果是在服务器启动并运行后执行的则为 false
version JBoss EAP 实例的版本号码。
user 已验证用户的用户名。如果和运行的服务器相同的主机为这个操作登记了日志,它将使用特殊的 $local 用户。
domainUUID 当所有操作从域控制器传播到服务器、从主机控制器和从主机控制器服务器时,链接所有操作的标识符。
access 它可以是下列值之一:NATIVE、HTTP、JMX。NATIVE - 操作通过原生管理接口进行,如 CLI。HTTP - 操作通过域 HTTP 接口进行,例如域控制台。JMX - 操作通过 JMX 子系统进行。关于如何配置 JMX 的审计日志,请参考 JMX 文档。
remote-address 执行这个操作的客户的地址。
success 如果操作成功则为 true,如果回滚则为 false
ops 被执行的操作。这是一个序列化到 JSON 的操作的列表。在引导时这是解析 XML 导致的所有操作。引导完成后,这个列表通常只包含单个条目。

第 4 章 用户管理

4.1. 用户创建

4.1.1. 为管理接口添加用户

概述

JBoss EAP 6 里的管理界面默认是设置了安全性的,因为一开始没有可用的用户帐号,除非你是用图形安装程序安装的。对于因简单配置错误而可能引起来自远程系统的攻击来说,这是一个预防措施。本地的非 HTTP 访问是受 SASL 机制保护的,就是当客户从 localhost 第一次连接时客户和服务器间都进行协商。

这个任务描述了如何创建初始的管理性用户,它可以使用基于 WEB 的管理控制台和管理 CLI 的远程实例来从远程系统上配置和管理 JBoss EAP 6。

注意

和 JBoss EAP 6 的 HTTP 通讯被当作是远程访问,即使这种通讯发生在本地主机。因此,你必须创建至少一个用户以能够使用管理控制台。如果你试图在添加用户前访问管理控制台,你将接收到一个错误,因为它在用户添加后才会被部署。

过程 4.1. 为远程管理界面创建初始管理性用户

  1. 调用 add-user.shadd-user.bat 脚本。

    进入 EAP_HOME/bin/ 目录。根据你的操作系统调用合适的脚本。
    红帽企业版 Linux
    [user@host bin]$ ./add-user.sh
    Microsoft Windows Server
    C:\bin>  add-user.bat
  2. 选择添加一个管理用户。

    点击 ENTER 选择默认选项 a 来添加一个管理用户。这个用户被添加到 ManagementRealm 并被授权通过基于 web 的管理控制台或基于命令行的管理 CLI 来执行管理操作。另外一个选项 b 则添加一个用户到 ApplicationRealm,且未提供特殊的权限。该区域(Realm)用于应用程序。
  3. 输入用户名和密码。

    遇到提示时输入用户名和密码,系统会提示您确认密码。
  4. 输入您的组信息

    添加用户所属的组或组群。如果用户属于多个组,请输入用逗号隔开的列表。如果不属于任何组,请留空。
  5. 获取信息并确认。

    系统会提示您确认信息。如果正确,请输入 yes
  6. 选择用户是否代表一个远程 JBoss EAP 6 服务器实例。

    除了管理员以外,偶尔需要在 ManagementRealm 里添加到 JBoss EAP 6 里的是代表其他 EAP 实例的用户,它需要通过验证作为成员加入到群集。下一个提示允许你指定所添加的用户。如果你选择 yes,你将得到一个 hashed secret 值,代表用户的密码,这将需要添加到不同的配置文件里。为了完成这个任务,在这里请回答 no
  7. 输入其他的用户。

    如果需要,重复刚才的过程你可以输入其他用户。你也可以在任何时候在运行系统里添加用户。不是选择默认的安全区,你需要添加用户到其他区以调整其授权过程。
  8. 非交互式地创建用户。

    通过在命令行传入参数,你可以非交互式地创建用户。我们不推荐在共享系统上使用这个方法,因为密码可以在日志或历史文件里看到。这个使用管理区域的命令的语法是:
    [user@host bin]$ ./add-user.sh usernamepassword
    要使用应用程序区域,请使用 -a 参数。
    [user@host bin]$ ./add-user.sh -a usernamepassword
  9. 通过 --silent 参数,你可以忽略 add-user 脚本的正常输出。这只有在指定了用户名密码且只使用了最小参数集时才适用。 而错误信息仍会被显示。
结果

你添加的任何用户都会在你指定的安全区里进行激活。ManagementRealm 区里活动的用户能够从远程系统里管理 JBoss EAP 6。

4.1.2. 传入参数到用户管理 add-user 脚本

您可以交互式地运行 add-user.shadd-user.bat 命令或将参数传入到命令行。本节描述了传入参数时可用的选项。
关于 add-user.shadd-user.bat 命令行的完整参数列表,请参考 第 4.1.3 节 “Add-user 命令行参数”
关于如何指定其他属性文件和位置,请参考 第 4.1.4 节 “指定用户管理信息的替代属性文件”
关于演示如何传递参数到 add-user.shadd-user.bat 命令行的示例,请参考 第 4.1.5 节 “Add-user 脚本命令行示例”

4.1.3. Add-user 命令行参数

下表描述了 add-user.shadd-user.bat 命令的可用参数。

表 4.1. Add-user 命令行参数

命令行参数 参数值 描述
-a
N/A
这个参数指定在应用程序区里创建用户。如果忽略,默认是在管理区里创建用户。
-dc
DOMAIN_CONFIGURATION_DIRECTORY
这个参数指定了包含属性文件的域配置目录。如果忽略,默认的目录是 EAP_HOME/domain/configuration/
-sc
SERVER_CONFIGURATION_DIRECTORY
这个参数指定了包含属性文件的其他独立服务器配置目录。如果忽略,默认的目录是 EAP_HOME/standalone/configuration/
-up
--user-properties
USER_PROPERTIES_FILE
这个参数指定其他用户属性文件的名称。它可以是一个绝对路径,也可以和 -sc-dc 参数一起来指定其他配置的目录。
-g
--group
GROUP_LIST
分配给这个用户的用逗号隔开的组的列表。
-gp
--group-properties
GROUP_PROPERTIES_FILE
这个参数指定其他组属性文件的名称。它可以是一个绝对路径,也可以和 -sc-dc 参数一起来指定其他配置的目录。
-p
--password
PASSWORD
用户的密码。密码必须满足下列要求:
  • 它不能和用户名相同。
  • 它必须包含至少 8 个字符。
  • 它必须包含至少一个字母数字字符。
  • 它必须包含至少一个数字。
  • 它必须包含至少一个非字母数字字符。
-u
--user
USER_NAME
用户的名称。
-r
--realm
REALM_NAME
用来设置管理接口安全性的区的名称。如果忽略,默认是 "ManagementRealm"。
-s
--silent
N/A
运行 add-user 脚本且不输出到控制台。
-h
--help
N/A
显示 add-user 脚本的用法。

4.1.4. 指定用户管理信息的替代属性文件

概述

在默认情况下,用 add-user.shadd-user.bat 创建的用户和角色信息都保存在服务器配置目录下的属性文件里。服务器配置信息保存在 EAP_HOME/standalone/configuration/ 目录而域配置信息保存在 EAP_HOME/domain/configuration/ 目录。本节将描述如何覆盖默认的文件名称和位置。

过程 4.2. 指定替代属性文件

    • 要指定服务器配置的替代目录,请使用 -sc 参数。这个参数指定了包含服务器配置属性文件的替代目录。
    • 要为域配置指定替代目录,,请使用 -dc 参数。这个参数指定了包含域配置属性文件的替代目录。
    • 要指定替代的用户配置属性文件,请使用 -up--user-properties 参数。它可以是绝对路径,也可以和 -sc-dc 参数一起使用来指定替代的配置目录。
    • 要指定替代的组配置属性文件,请使用 -gp--group-properties 参数。它可以是绝对路径,也可以和 -sc-dc 参数一起使用来指定替代的配置目录。

注意

add-user 命令旨在操作现有的属性文件。命令行里指定任何替代属性文件都必须存在,否则您将看到下列错误:
JBAS015234: No appusers.properties files found
关于命令参数的更多信息,请参考 第 4.1.3 节 “Add-user 命令行参数”
关于 add-user 命令的示例,请参考 第 4.1.5 节 “Add-user 脚本命令行示例”

4.1.5. Add-user 脚本命令行示例

下面的例子演示了如何传递参数到 add-user.shadd-user.bat 命令。除非另有注明,这些命令假定是使用独立服务器配置的。

例 4.1. 创建属于使用默认属性文件的单个组的用户。

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest'
上面的命令产生下列结果。
  • 用户 appuser1 被添加到保存用户信息的下列默认属性文件里。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • 用户 appuser1 和组 guest 被添加到保存组信息的默认属性文件里。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例 4.2. 创建属于使用默认属性文件的多个组的用户。

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest,app1group,app2group'
上面的命令产生下列结果。
  • 用户 appuser1 被添加到保存用户信息的下列默认属性文件里。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • 用户 appuser1 和组 guestapp1groupapp2group被添加到保存组信息的默认属性文件里。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例 4.3. 在使用默认属性文件的默认区里创建带有管理权限的用户。

EAP_HOME/bin/add-user.sh -u 'adminuser1' -p 'password1!' -g 'admin'
上面的命令产生下列结果。
  • 用户 adminuser1 被添加到保存用户信息的下列默认属性文件里。
    EAP_HOME/standalone/configuration/mgmt-users.properties
    EAP_HOME/domain/configuration/mgmt-users.properties
  • 用户 adminuser1 和组 admin 被添加到保存组信息的默认属性文件里。
    EAP_HOME/standalone/configuration/mgmt-groups.properties
    EAP_HOME/domain/configuration/mgmt-groups.properties

例 4.4. 创建属于用替代属性文件保存信息的单个组的用户。

EAP_HOME/bin/add-user.sh -a -u appuser1 -p password1! -g app1group -sc /home/someusername/userconfigs/ -up appusers.properties -gp appgroups.properties 
上面的命令产生下列结果。
  • 我们添加了用户 appuser1 到下列属性文件里,它现在是保存用户信息的默认文件。
    /home/someusername/userconfigs/appusers.properties
  • 我们添加了用户 appuser1 和组 app1group 到下列属性文件里,它现在是保存组信息的默认文件。
    /home/someusername/userconfigs/appgroups.properties

第 5 章 网络和端口配置

5.1. 接口

5.1.1. 关于接口

应用服务器在整个配置里都使用命名接口引用。这让配置可以用逻辑名称引用单独的接口声明,而不是每次都使用整个接口细节。逻辑名称的使用也保持了组引用和命名接口的一致性,而受管域上的服务器实例可能包含多个主机上不同的接口细节。使用这个方法,每个服务器实例可能对应逻辑名称组,它可以将接口组作为整体进行管理。
网络接口是通过指定逻辑名和物理接口的选择标准来声明的。应用服务器附带有用于管理及公共接口名称的默认配置。在这个配置里,公共接口组的目的是用于和应用程序相关的网络通讯,如 Web 或 Messaging。管理接口组的目的是用于管理层要求的所有组件和服务,包括 HTTP 管理端点。接口名自身是仅作为建议来提供的,任何组的名称都可以按照需要进行替换和创建。
domain.xml, host.xmlstandalone.xml 都包含了接口声明。声明标准可以引用通配符地址或指定接口或地址必须具有来进行有效匹配的一个或多个特征。下面的例子展示了接口声明的多个可能的配置,它们通常是在 standalone.xmlhost.xml 配置文件里定义的。这允许任何远程主机组维护自己所专有的接口属性,且仍然允许对域控制器里的 domain.xml 配置文件里任何接口组的引用。
第一个例子展示了为 managementpublic 相对名称组指定的专有的 inet-address 值。

例 5.1. 用 inet-address 值创建的接口组

<interfaces>
  <interface name="management">
   <inet-address value="127.0.0.1"/>
  </interface>
  <interface name="public">
   <inet-address value="127.0.0.1"/>
  </interface>
</interfaces>


在下面的例子里,全局接口组使用了 any-address 元素来声明通配符地址。

例 5.2. 用通配符声明创建的全局组

<interface name="global">
   <!-- Use the wild-card address -->
   <any-address/>
</interface>


下面的例子声明了名为 external 的相对组下的一个网络接口卡。

例 5.3. 用 NIC 值创建的外部组

        
<interface name="external">
   <nic name="eth0"/>
</interface>


在下面的例子里,根据专有需求,声明作为默认组创建。在这个实例里,其他元素的特征为接口设置了条件以进行有效的匹配。这允许每个专有接口声明组的创建,且能够以当前模式引用它们,从而减少了跨多个服务器实例的配置和管理。

例 5.4. 用专有条件值创建的默认组

<interface name="default">
   <!-- Match any interface/address on the right subnet if it's
        up, supports multicast, and isn't point-to-point -->
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>


虽然接口声明可以在源配置文件里创建和编辑,管理 CLI 和管理控制台为配置的修改提供了安全的、可控和持久性的环境。

5.1.2. 配置接口

standalone.xmlhost.xml 配置文件里默认的接口配置通常提供三个带有相对接口令牌的命名接口。您可以使用管理控制台或管理 CLI 来配置下表列出的其他属性和值。你也可以按需要用专有值替换相对的接口绑定。请注意,如果您这样做,您将无法在运行时传入接口值,因为 -b 选项只能覆盖相对值。

例 5.5. 默认的接口配置

        <interfaces>
            <interface name="management">
                <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
            </interface>
            <interface name="public">
                <inet-address value="${jboss.bind.address:127.0.0.1}"/>
            </interface>
            <interface name="unsecure">
                <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
            </interface>
        </interfaces>

表 5.1. 接口属性和值

接口元素 描述
any 地址排斥类型的空元素,用于约束选择标准。
any-address 空元素表示使用这个接口的套接字应该绑定到通配符地址。除非设置 java.net.preferIpV4Stack 系统属性为 true,否则 IPv6 将使用通配符地址(::),而 IPv4 将使用通配符地址(0.0.0.0)。如果套接字绑定到双栈主机上的任何本地 IPv6 地址,它可以接受 IPv6 及 IPv4 数据。如果绑定到任何的本地 IPv4 地址,它就只能接受 IPv4 数据。
any-ipv4-address 空元素表示使用这个接口的套接字应该绑定到 IPv4 通配符地址(0.0.0.0)。
any-ipv6-address 空元素表示使用这个接口的套接字应该绑定到 IPv6 通配符地址(::)。
inet-address 请输入 IPv6 格式的 IP 地址或者用小数点隔开的 IPv4 地址,或者可以解析为 IP 地址的主机名。
link-local-address 空元素表示接口的部分选择标准应该是或不是和 link-local 关联的地址。
loopback 空元素表示接口的部分选择标准应该是或不是 loopback 接口。
loopback-address 可能实际上不会在主机的 loopback 接口上配置的 loopback 地址。和 inet-addressType 不同的是,即使没有找到和 IP 地址相关的 NIC,给定的值也将被使用。
multicast 空元素表示接口的部分选择标准应该支持或不支持多点传送。
nic 网络接口的名称(如 eth0, eth1, lo) 。
nic-match 常规表达式,表示主机上可以映射可接受的接口的网络接口的名称。
not 地址排斥类型的空元素,用于约束选择标准。
point-to-point 空元素表示接口的部分选择标准是是否为 point-to-point 接口。
public-address 空元素表示接口的部分选择标准应该有或没有公共路由的地址。
site-local-address 空元素表示接口的部分选择标准应该是或不是和 site-local 关联的地址。
subnet-match 网络 IP 地址和地址的网络前缀的位数,以斜杠和数字表示;如 "192.168.0.0/16"。
up 空元素表示接口的部分选择标准应该是或不是正在运行。
virtual 空元素表示接口的部分选择标准应该是或不是虚拟接口。
  • 配置接口属性

    请选择管理 CLI 或管理控制台来按需要配置接口属性。
    • 用管理 CLI 配置接口属性

      使用管理 CLI 来添加新的接口并编写新的接口属性的值。
      1. 添加新的接口

        使用 add 操作来创建新的接口。您可以在管理 CLI 会话的根目录里运行这个命令,下面的例子创建了一个名为 interfacename 的接口,它将 inet-address 声明为 12.0.0.2
        /interface=interfacename/:add(inet-address=12.0.0.2)
      2. 编辑接口属性

        使用 write 操作来编写新的属性的值。您可以使用 tab completion 来帮助输入并提示所有可用的值。下面的例子将 inet-address 的值更新为 12.0.0.8
        /interface=interfacename/:write(inet-address=12.0.0.8)
      3. 编辑接口属性

        通过 include-runtime=true 参数运行 read-resource 操作来确认值已修改以开放服务器模型里所有当前的值。
        [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)
    • 用管理控制台配置接口属性

      使用管理控制台来添加新的接口并编写新的接口属性的值。
      1. 登录到管理控制台。

        登录到受管域或独立服务器实例的管理控制台。
      2. 如果您使用了受管域,请选择正确的配置集。

        选择右上角的 Profiles 标签,然后从下一屏幕的 Profile 里选择正确的配置集。
      3. 从导航菜单里选择 Interfaces 条目。

        从导航菜单里选择 Interfaces 菜单条目。
      4. 添加新的接口

        1. 点击 Add 按钮。
        2. 输入 NameInet AddressAddress Wildcard 的值。
        3. 点击“Save”完成。
      5. 编辑接口属性

        1. 选择要编辑的接口并点击 Edit 按钮。
        2. 输入 NameInet AddressAddress Wildcard 的值。
        3. 点击“Save”完成。

5.2. 套接字绑定组

5.2.1. 关于套接字绑定组

套接字绑定和绑定组允许您定义网络接口及它们和 JBoss EAP 6 配置要求的网络接口的关系。
套接字绑定是用于套接字的命名配置。这些命名配置的声明可以在 domain.xmlstandalone.xml 配置文件里找到。配置的其他部分可以通过逻辑名引用这些套接字,而无需包含套接字配置的完整细节。这允许您引用不同主机上可能不同的相对套接字配置。
套接字绑定是通过套接字组来收集的。套接字绑定组是按照逻辑名称分组的套接字绑定声明的集合。然后这个命名组可以在整个配置里进行引用。独立服务器配置只包含一个这样的组,而受管域实例则可以包含多个组。您可以在受管域里为每个服务器组创建一个套接字绑定组,或者在多个服务器组间分享套接字绑定组。
在配置受管域的服务器组时,命名组允许对特定的套接字绑定组使用简化的引用。另外一个通常的用途是对同一个系统上的多个独立服务器实例的配置和管理。下面的例子分别展示了独立和域实例的配置文件里的默认套接字绑定组。

例 5.6. 独立配置的默认套接字绑定

standalone.xml 配置文件里的默认套接字绑定组是按照 standard-sockets 分组的。public 接口也通过相同的逻辑引用方法引用了这个组。
   
<socket-binding-group name="standard-sockets" default-interface="public">
    <socket-binding name="http" port="8080"/>
    <socket-binding name="https" port="8443"/>
    <socket-binding name="jacorb" port="3528"/>
    <socket-binding name="jacorb-ssl" port="3529"/>
    <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
    <socket-binding name="jmx-connector-server" port="1091" interface="management"/>
    <socket-binding name="jndi" port="1099"/>
    <socket-binding name="messaging" port="5445"/>
    <socket-binding name="messaging-throughput" port="5455"/>
    <socket-binding name="osgi-http" port="8090" interface="management"/>
    <socket-binding name="remoting" port="4447"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
</socket-binding-group>

例 5.7. 域配置的默认套接字绑定

domain.xml 配置文件里的默认套接字绑定组包含了四个组:standard-socketsha-socketsfull-socketsfull-ha-sockets。这些组也被名为 public 的接口所引用。
<socket-binding-groups>
    <socket-binding-group name="standard-sockets" default-interface="public">
        <!-- Needed for server groups using the 'default' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
    <socket-binding-group name="ha-sockets" default-interface="public">
        <!-- Needed for server groups using the 'ha' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" port="57600"/>
        <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" port="54200"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
    <socket-binding-group name="full-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jacorb" interface="unsecure" port="3528"/>
        <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
    <socket-binding-group name="full-ha-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full-ha' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jacorb" interface="unsecure" port="3528"/>
        <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" port="57600"/>
        <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" port="54200"/>
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
</socket-binding-groups>

套接字绑定实例可以在应用服务器目录下的 standalone.xmldomain.xml 文件里创建和编辑。我们推荐的管理绑定的方法是使用管理控制台或管理 CLI。使用管理控制台的优势包括图形化的用户界面,在 General Configuration 部分里有专门的 Socket Binding Group 屏幕。管理 CLI 提供 API 和基于命令行的批处理工作流程,并可以对应用服务器配置的更高和更低级别使用脚本。两种界面都可以持久化修改或者保存修改到服务器配置文件里。

5.2.2. 配置套接字绑定

套接字绑定可以在唯一的套接字绑定组里定义。独立服务器包含一个 standard-sockets 组,且无法创建更多的组。相反,您可以创建替代的独立服务器配置文件。对于受管域,您可以创建多个套接字绑定组并按需要配置它们包含的套接字绑定。下表展示了每个套接字绑定的可用属性。

表 5.2. 套接字绑定属性

组件 描述 角色
名称 应该用在配置里其他位置的套接字配置的逻辑名。 要求的
端口 基于这个配置的套接字应该绑定的基础端口。请注意,您可以通过应用于所有端口的增量或减量来配置服务器以覆盖这个基础值。 要求的
接口 基于这个配置的套接字应该绑定的接口的逻辑名。如果没有定义,将会使用附带的套接字绑定组里 "default-interface" 属性的值。 自选的
多点传送地址 如果套接字用于多点传送,要使用的多点传送地址。 自选的
多点传送接口 绑定到会话的生命周期。会话作用域处于请求长度和会话之间,由应用程序控制。 自选的
固定端口 如果上面的上下文没有满足您的需要,您可以定义自定义作用域。 自选的
  • 配置套接字绑定组里的套接字绑定

    请选择管理 CLI 或管理控制台来按需要配置套接字绑定。
    • 使用管理 CLI 配置套接字绑定

      使用管理 CLI 配置套接字绑定。
      1. 添加新的套接字绑定

        如果有需要,请使用 add 操作来创建新的地址设置。您可以在管理 CLI 会话的根目录里运行这个命令,下面的例子创建了一个名为 newsocket 的套接字绑定,它的 port 属性声明为 1234。这些例子适用于独立服务器和受管域的 standard-sockets 套接字绑定组。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)
      2. 编辑 Pattern 属性

        使用 write-attribute 操作来编写新的属性的值。您可以使用 tab completion 来帮助输入并提示所有可用的值。下面的例子将 port 的值更新为 2020
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)
      3. 确认 Pattern 属性

        通过 include-runtime=true 参数运行 read-resource 操作来确认值已修改以开放服务器模型里所有当前的值。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource
    • 使用管理控制台配置套接字绑定

      使用管理控制台配置套接字绑定。
      1. 登录到管理控制台。

        登录到受管域或独立服务器的管理控制台。
      2. 选择 Profile tab

        从控制台的右上角选择 Profiles 标签页。
      3. 从导航菜单里选择 Socket Binding 菜单条目。

        从导航菜单里选择 Socket Binding 条目。如果您使用受管域,请选择 Socket Binding Groups 菜单里的组。
      4. 添加新的套接字绑定

        1. 点击 Add 按钮。
        2. 输入 Name, PortBinding Group 的值。
        3. 点击“Save”完成。
      5. 编辑接口属性

        1. 选择要编辑的套接字绑定并点击 Edit 按钮。
        2. 输入 Name, InterfacePort 的值。
        3. 点击“Save”完成。

5.2.3. JBoss EAP 6 使用的网络端口

JBoss EAP 6 的默认配置使用的端口取决于下列因素:
  • 你的服务器组是否使用了默认的套接字绑定组,或者自定义的套接字绑定组。
  • 单独部署的要求。

注意

你可以配置一个数字的端口偏移量,以减缓当在同一个服务服务器上运行多个服务器时端口冲突。如果你的服务器使用了数字的端口偏移量,在它的服务器组的套接字绑定组的默认端口上添加偏移量。例如,如果套接字绑定组的 HTTP 端口是 8080,而你的服务器使用了端口偏移量为 100,那么它的 HTTP 端口是 8180。
除非额外指定,这个端口将使用 TCP 协议。

默认的套接字绑定组

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

表 5.3. 默认的套接字绑定组的引用

名称 端口 多点传送端口 描述 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ 协议,用于 HTTP 群集和负载平衡。
http 8080 用于已部署应用程序的默认端口。
https 8443 已部署的应用程序和客户间的用 SSL 加密的连接。
jacorb 3528 用于 JTS 事务的 CORBA 服务和其他依赖于 ORB 的服务。
jacorb-ssl 3529 SSL 加密的 CORBA 服务。
jgroups-diagnostics 7500 多点传送。用于 HA 群集里的 Peer 发现。不能使用管理界面进行配置。
jgroups-mping 45700 多点传送。用于在 HA 群集里发现初始成员资格。
jgroups-tcp 7600 HA 群集里使用 TCP 的多点传送 Peer 发现。
jgroups-tcp-fd 57600 用于 TCP 上的 HA 失败检测。
jgroups-udp 55200 45688 HA 群集里使用 UDP 的多点传送 Peer 发现。
jgroups-udp-fd 54200 用于 UDP 上的 HA 失败检测。
messaging 5445 JMS 服务。
messaging-group 被 HornetQ JMS 广播和发现组引用。
messaging-throughput 5455 JMS remoting 所使用的。
mod_cluster 23364 用于 JBoss EAP 6 和 HTTP 加载平衡器之间通讯的多点传送端口。
osgi-http 8090 由使用 OSGi 子系统的内部组件使用。不能通过管理界面进行配置。
remoting 4447 用于远程 EJB 调用。
txn-recovery-environment 4712 JTA 事务恢复管理者。
txn-status-manager 4713 JTA / JTS 事务管理者。
管理端口

除了套接字绑定组,每个主机控制台都打开另外两个端口用于管理:

  • 9990 - Web 管理控制台的端口
  • 9999 - 管理控制台和 API 使用的端口

5.2.4. 关于套接字绑定组的端口偏移

端口偏移是添加到服务器的套接字组给定的端口值的数字偏移量。这允许单个服务器继承服务器组的套接字绑定,并用偏移量来确保它和组里的其他服务器不冲突。例如,如果套接字绑定组的 HTTP 端口是 8080,而你的服务器使用了端口偏移量为 100,那么它的 HTTP 端口是 8180。

5.2.5. 配置端口偏移

  • 配置端口偏移

    选择管理 CLI 或管理控制台来配置您的端口偏移。
    • 使用管理 CLI 配置端口偏移

      使用管理 CLI 来配置端口偏移。
      1. 编辑端口偏移

        使用 write-attribute 操作来为端口偏移属性编写新的值。下面的例子更新了 server-twosocket-binding-port-offset 值为 250。这个服务器是默认本地主机组的成员。为使改动生效,服务器需要重启。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
      2. 确认端口偏移属性

        运行 read-resource 操作并使用 include-runtime=true 参数来开放服务器模型里当前所有的值,从而确认修改。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)
    • 使用管理控制台来配置端口偏移

      使用管理控制台来配置端口偏移。
      1. 登录到管理控制台。

        登录到您的受管域的管理控制台。
      2. 选择 Hosts 标签页

        选择右上角的 Hosts 标签页。
      3. 编辑端口偏移属性

        1. 选择 Configuration Name 里的服务器并点击 Edit 按钮。
        2. Port Offset 字段里输入想要的值。
        3. 点击 Save 按钮完成。

5.3. IPv6

5.3.1. 配置 IPv6 网络的 JVM Stack 首选项

总结
本节涵盖为 JBoss EAP 6 安装启用 IPv6 网络。

过程 5.1. 禁用 IPv4 Stack Java 属性

  1. 打开相关的安装文件:
    • 对于独立服务器:

      打开 EAP_HOME/bin/standalone.conf
    • 对于受管域:

      打开 EAP_HOME/bin/domain.conf
  2. 修改 IPv4 Stack Java 属性为 false:
    -Djava.net.preferIPv4Stack=false
    例如:
    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

5.3.2. 配置 IPv6 网络的接口声明

总结

遵循下列步骤来配置 IPv6 的接口 inet 地址:

过程 5.2. 配置 IPv6 网络的接口

  1. 请选择控制台右上角的 Profile 标签页。
  2. 选择 General Configuration 下的 Interfaces 选项。
  3. 选择要配置的命名网络接口。
  4. 点击 Edit 按钮。
  5. 设置 inet 地址为:
    ${jboss.bind.address.management:[ADDRESS]}
  6. 点击 Save 按钮来保存修改。
  7. 重启服务器来应用这些修改。

5.3.3. 配置 IPv6 地址的 JVM Stack 首选项

总结
本节涵盖通过配置文件配置 JBoss EAP 6 安装首选 IPv6 地址。

过程 5.3. 配置 JBoss EAP 6 安装首选 IPv6 地址

  1. 打开相关的安装文件:
    • 对于独立服务器:

      打开 EAP_HOME/bin/standalone.conf
    • 对于受管域:

      打开 EAP_HOME/bin/domain.conf
  2. 附加下列 Java 属性到 Java VM 选项:
    -Djava.net.preferIPv6Addresses=true
    例如:
    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

第 6 章 数据源管理

6.1. 简介

6.1.1. 关于 JDBC

JDBC API 是定义 Java 应用程序如何访问数据库的标准。应用程序配置引用 JDBC 驱动的数据源。然后可以再次针对驱动而不是数据库编写应用程序代码。驱动将代码转换为数据库语言。这表示如果安装了正确的驱动,应用程序就可以使用受支持的数据库了。
JDBC 4.0 规格是在这里定义的:http://jcp.org/en/jsr/detail?id=221
要开始使用 JDBC 和数据源,请参考 JBoss EAP 6 的《管理和配置指南》里的《JDBC 驱动》章节。

6.1.2. JBoss EAP 6 支持的数据库

关于 JBoss EAP 6 支持的兼容 JDBC 的数据库列表,请参考:https://access.redhat.com/site/articles/111663

6.1.3. 数据源的类型

两种常用的资源类型是非 XA 数据源XA 数据源
非 XA 数据源用于不使用事务的应用程序,或者以单个数据库使用事务的应用程序。
XA 数据源用于事务分布在多个数据库的应用程序。XA 数据源会导致额外的负荷。
当你在管理控制台或管理 CLI 里创建数据源时,你可以指定它的类型。

6.1.4. 数据源示例

JBoss EAP 6 里包含了一个 H2 数据源,它是一个轻量级的关系型数据库管理系统,它为开发者提供了快速构建应用程序的能力,而且是平台的示例数据源。

警告

然而,JBoss EAP 附带的示例数据源不应该用于产品环境。它是一个非常小、自包容的数据源,它支持所有测试和构建应用程序所需的标准,但它并不健壮也不具有足够的可扩充性以用于产品环境。
关于被支持和认证的数据源,请参考 第 6.1.2 节 “JBoss EAP 6 支持的数据库”

6.1.5. -ds.xml 文件的部署

在 JBoss EAP 6 里,数据源被定义为服务器子系统的资源。在以前的版本里,服务器配置的 deploy 目录里要求有 *-ds.xml 数据源配置文件。*-ds.xml 文件仍可以按照Schemas 这里http://www.ironjacamar.org/documentation.html 的 1.1 数据源模式部署在 JBoss EAP 6 里。

警告

这个功能应该只用于部署。我们不推荐将其用于产品环境,因为 JBoss 管理工具并不支持它。

重要

当部署 *-ds.xml 文件时,使用对已部署 / 定义的<driver> 条目的引用是强制的。

6.2. JDBC 驱动

6.2.1. 用管理控制台安装 JDBC 驱动

介绍

在你的应用程序可以连接 JDBC 数据源之前,你的数据源供应商的 JDBC 驱动需要安装在 JBoss EAP 可以使用的位置上。JBoss EAP 6 允许你象其他部署一样部署这些驱动。这意味着如果你使用了受管域,你可以将它们部署在服务器组里的多个服务器上。

注意

考虑到更好的服务器启动行为,JDBC 驱动的首选安装方法是作为核心模块安装。要将 JDBC 驱动安装为核心模块,请参考:第 6.2.2 节 “将 JDBC 驱动安装为核心模块”
先决条件

在执行这个任务之前,你需要满足以下预备条件:

  • 从数据库供应商下载 JDBC 驱动。

过程 6.1. 部署 JDBC 驱动

  1. 访问管理控制台。

  2. 将 JAR 文件部署到服务器或服务器组。

    如果你使用了受管域,你可以将 JAR 文件部署到服务器组。否则,部署到自己的服务器。请参考 第 9.2.2 节 “使用管理控制台部署应用程序”
结果:

JDBC 驱动被部署,可由你的应用程序所使用。

6.2.2. 将 JDBC 驱动安装为核心模块

先决条件

在执行这个任务之前,你需要满足以下预备条件:

过程 6.2. 将 JDBC 驱动安装为核心模块

  1. EAP_HOME/modules/ 目录下创建一个文件路径结构。例如,对于 MySQL JDBC 驱动,创建下列目录结构:EAP_HOME/modules/com/mysql/main/
  2. 将 JDBC 驱动的 JAR 文件复制到 main/ 子目录。
  3. main/ 子目录里,创建一个类似于下列示例的 module.xml 文件: 第 7.1.1 节 “模块”module XSD 在 EAP_HOME/docs/schema/module-1_2.xsd 文件里进行定义。
  4. 启动服务器。
  5. 启动管理 CLI。
  6. 运行下列 CLI 命令将 JDBC 模块添加为驱动:
    /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)

    例 6.1. CLI 名利示例

    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
结果

已安装好 JDBC 驱动并设置为核心模块,且可以被应用程序数据源引用。

6.2.3. JDBC 驱动的下载位置

下表列出了 JBoss EAP 6 常用的数据库的 JDBC 驱动的下载位置。这些链接指向不受 Red Hat 监控或控制的第三方网站。关于您的数据库的最新驱动,请参考相关数据库供应商的文档和网站。

6.2.4. 访问供应商专有的类

总结

本节涵盖使用 JDBC 专有类所需的步骤。当应用程序需要使用非 JDBC API 一部分的供应商专有功能时这是有必要的。

警告

这是高级的应用。只有需要 JDBC API 里找不到的功能时才应该实现这个过程。

重要

在使用重验证机制并访问供应商专有的类时这个过程是必需的。

重要

因为这个连接是被 Iron Jacamar 容器控制的,请严格遵循供应商专有的 API 准则。

过程 6.3. 在应用程序里添加依赖关系

    • 配置 MANIFEST.MF 文件

      1. 在文本编辑器里打开应用程序的 META-INF/MANIFEST.MF 文件。
      2. 为 JDBC 模块添加一个依赖关系并保存文件。
        依赖关系:MODULE_NAME

        例 6.2. 依赖关系示例

        依赖关系:com.mysql
      1. 创建一个 jboss-deployment-structure.xml 文件

        在应用程序的 META-INF/ or WEB-INF 文件夹里创建一个名为 jboss-deployment-structure.xml 的文件。

        例 6.3. jboss-deployment-structure.xml 文件示例

        <jboss-deployment-structure>
          <deployment>
            <dependencies>
              <module name="com.mysql" />
            </dependencies>
          </deployment>
        </jboss-deployment-structure>
        
        

例 6.4. 访问供应商专有的 API

下面的例子访问了 MySQL API。
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();

6.3. Non-XA 数据源

6.3.1. 用管理界面创建一个 Non-XA 数据源

总结

本节涵盖用管理控制台或管理 CLI 创建 Non-XA 数据源所需的步骤。

前提条件

  • JBoss EAP 6 服务器必须正在运行。

注意

在 Oracle 数据源 10.2 之前的版本里,<no-tx-separate-pools/> 参数是必需的,因为非事务性和事务性连接的混合可能导致错误。对于某些应用程序来说,这个参数已不再是必需的了。

过程 6.4. 用管理 CLI 或管理控制台创建一个数据源

    • 管理 CLI

      1. 启动 CLI 工具并连接到您的服务器。
      2. 运行下列命令来创建 Non-XA 数据源,配置合适的变量:
        data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
      3. 启用数据源:
        data-source enable --name=DATASOURCE_NAME
    • 管理控制台

      1. 登陆到管理控制台。
      2. 进入管理控制台的 Datasources 面板

          • 独立模式

            从控制台的顶部选择 Profile 标签页。
          • 域模式

            1. 从控制台的顶部选择 Profiles 标签页。
            2. 从左上角的下拉菜单里选择合适的配置集。
            3. 展开控制台左侧的 Subsystems 菜单。
        1. 从控制台左侧的菜单里选择 ConnectorDatasources
      3. 创建新的数据源

        1. 选择 Datasources 面板顶部的 Add 按钮。
        2. Create Datasource 向导里输入新的数据源属性并点击 Next 按钮。
        3. Create Datasource 向导里输入 JDBC 驱动细节并点击 Next 按钮。
        4. Create Datasource 向导里输入连接设置并点击 Done 按钮。
结果

Non-XA 数据源已被添加至服务器。它在 standalone.xmldomain.xml 文件以及管理界面里都可见。

6.3.2. 用管理界面修改 Non-XA 数据源

总结

本节涵盖用管理控制台或管理 CLI 修改 Non-XA 数据源所需的步骤。

注意

Non-XA 数据源可以和 JTA 事务继承。要继承数据源和 JTA,请确保 jta 参数被设置为 true

过程 6.5. 修改 Non-XA 数据源

    • 管理 CLI

      1. 使用 write-attribute 命令来配置数据源属性:
        /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
      2. 重载服务器来确认修改:
        :reload
    • 管理控制台

      1. 进入管理控制台的 Datasources 面板

          • 独立模式

            从控制台的顶部选择 Profile 标签页。
          • 域模式

            1. 从控制台的顶部选择 Profiles 标签页。
            2. 从左上角的下拉菜单里选择合适的配置集。
            3. 展开控制台左侧的 Subsystems 菜单。
        1. 从控制台左侧的菜单里选择 ConnectorDatasources
      2. 编辑数据源

        1. Available Datasources 列表里选择相关的数据源。数据源属性显示在下面的 Attributes 面板上。
        2. 选择 Edit 按钮来编辑数据源属性。
        3. 编辑数据源属性并在完成时选择 Save 按钮。
结果

已完成对 Non-XA 数据源的配置。这些修改在 standalone.xmldomain.xml 文件以及管理界面里都可见。

6.3.3. 用管理界面删除 Non-XA 数据源

总结

本节涵盖用管理控制台或管理 CLI 从 JBoss EAP 6 删除 Non-XA 数据源所需的步骤。

过程 6.6. 删除 Non-XA 数据源

    • 管理 CLI

      1. 运行下列命令来删除 Non-XA 数据源:
        data-source remove --name=DATASOURCE_NAME
    • 管理控制台

      1. 进入管理控制台的 Datasources 面板

          • 独立模式

            从控制台的顶部选择 Profile 标签页。
          • 域模式

            1. 从控制台的顶部选择 Profiles 标签页。
            2. 从左上角的下拉菜单里选择合适的配置集。
            3. 展开控制台左侧的 Subsystems 菜单。
        1. 从控制台左侧的菜单里选择 ConnectorDatasources
      2. 选择要删除的数据源,并点击控制台右上角的 Remove 按钮。
结果

非 XA 数据源已从服务器删除。

6.4. XA 数据源

6.4.1. 用管理界面创建 XA 数据源

总结

本节涵盖用管理控制台或管理 CLI 创建 XA 数据源所需的步骤。

注意

在 Oracle 数据源 10.2 之前的版本里,<no-tx-separate-pools/> 参数是必需的,因为非事务性和事务性连接的混合可能导致错误。对于某些应用程序来说,这个参数已不再是必需的了。

过程 6.7. 用管理 CLI 或管理控制台创建 XA 数据源

    • 管理 CLI

      1. 运行下列命令来创建 XA 数据源,配置合适的变量:
        xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS
      2. 配置 XA 数据源属性

        1. 设置服务器名称

          运行下列命令来配置主机的服务器名称:
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)
        2. 设置数据库名称

          运行下列命令来配置数据库名称:
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
      3. 启用数据源:
        xa-data-source enable --name=XA_DATASOURCE_NAME
    • 管理控制台

      1. 进入管理控制台的 Datasources 面板

          • 独立模式

            从控制台的顶部选择 Profile 标签页。
          • 域模式

            1. 从控制台的顶部选择 Profiles 标签页。
            2. 从左上角的下拉菜单里选择合适的配置集。
            3. 展开控制台左侧的 Subsystems 菜单。
        1. 从控制台左侧的菜单里选择 ConnectorDatasources
      2. 选择 XA Datasource 标签页。
      3. 创建新的 XA 数据源

        1. 选择 XA Datasources 面板顶部的 Add 按钮。
        2. Create XA Datasource 向导里输入新的 XA 数据源属性并点击 Next 按钮。
        3. Create XA Datasource 向导里输入 JDBC 驱动细节并点击 Next 按钮。
        4. 编辑 XA 属性并点击 Next 按钮。
        5. Create XA Datasource 向导里输入连接设置并点击 Done 按钮。
结果

XA 数据源已被添加至服务器。它在 standalone.xmldomain.xml 文件以及管理界面里都可见。

6.4.2. 用管理界面修改 XA 数据源

总结

本节涵盖用管理控制台或管理 CLI 修改 XA 数据源所需的步骤。

过程 6.8. 用管理 CLI 或管理控制台修改 XA 数据源

    • 管理 CLI

      1. 配置 XA 数据源属性

        使用 write-attribute 命令来配置数据源属性:
        /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
      2. 配置 XA 数据源属性

        运行下列命令来配置 XA 数据源子资源:
        /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      3. 重载服务器来确认修改:
        :reload
    • 管理控制台

      1. 进入管理控制台的 Datasources 面板

          • 独立模式

            从控制台的顶部选择 Profile 标签页。
          • 域模式

            1. 从控制台的顶部选择 Profiles 标签页。
            2. 从左上角的下拉菜单里选择合适的配置集。
            3. 展开控制台左侧的 Subsystems 菜单。
        1. 从控制台左侧的菜单里选择 ConnectorDatasources
      2. 选择 XA Datasource 标签页。
      3. 编辑数据源

        1. Available XA Datasources 列表里选择相关的数据源。XA 数据源属性显示在下面的 Attributes 面板上。
        2. 选择 Edit 按钮来编辑数据源属性。
        3. 编辑 XA 数据源属性并在完成时选择 Save 按钮。
结果

已完成对 XA 数据源的配置。这些修改在 standalone.xmldomain.xml 文件以及管理界面里都可见。

6.4.3. 用管理界面删除 XA 数据源

总结

本节涵盖用管理控制台或管理 CLI 从 JBoss EAP 6 删除 XA 数据源所需的步骤。

过程 6.9. 用管理 CLI 或管理控制台删除 XA 数据源

    • 管理 CLI

      1. 运行下列命令来删除 XA 数据源:
        xa-data-source remove --name=XA_DATASOURCE_NAME
    • 管理控制台

      1. 进入管理控制台的 Datasources 面板

          • 独立模式

            从控制台的顶部选择 Profile 标签页。
          • 域模式

            1. 从控制台的顶部选择 Profiles 标签页。
            2. 从左上角的下拉菜单里选择合适的配置集。
            3. 展开控制台左侧的 Subsystems 菜单。
        1. 从控制台左侧的菜单里选择 ConnectorDatasources
      2. 选择 XA Datasource 标签页。
      3. 选择要删除的 XA 数据源,并点击控制台右上角的 Remove 按钮。
结果

XA 数据源已从服务器删除。

6.4.4. XA 恢复

6.4.4.1. 关于 XA Recovery 模块

每个 XA 资源都需要一个 recovery 模块与其配置相关联。这个 recovery 模块必须继承 com.arjuna.ats.jta.recovery.XAResourceRecovery
JBoss EAP 6 为 JDBC 和 JMS XA 资源提供了 recovery 模块。对于这些类型的资源,recovery 模块会自动注册。如果您需要使用自定义模块,您可以在自己的数据源里注册它。

6.4.4.2. 配置 XA Recovery 模块

对于多数 JDBC 和 JMS 资源,recovery 模块自动和资源相关联。在这些情况下,您只需要配置选项以允许 recovery 模块连接到您的资源来执行恢复。
对于非 JDBC 或 JMS 的自定义资源,请联系 Red Hat 全球支持服务获取受支持的配置的信息。
每个配置属性都可以在数据源创建过程中或之后设置。你可以用基于 web 的管理控制台或命令行管理 CLI 进行设置。关于配置 XA 数据源的信息,请参考 第 6.4.1 节 “用管理界面创建 XA 数据源”第 6.4.2 节 “用管理界面修改 XA 数据源”
参考下列表里的常用数据源配置属性,以及和专有数据库供应商相关的配置细节。

表 6.2. 常用的配置属性

属性 描述
recovery-username
recovery 模块应该用来连接资源进行恢复的用户名。
recovery-password
recovery 模块应该用来连接资源进行恢复的密码。
recovery-security-domain
recovery 模块应该用来连接资源进行恢复的安全域。
recovery-plugin-class-name
如果你需要使用自定义的 recovery 模块,请将这个属性设置为模块的全限定名。这个模块应该继承 com.arjuna.ats.jta.recovery.XAResourceRecovery 类。
recovery-plugin-properties
如果你使用了要求设置属性的自定义 recovery 模块,请将这个属性设置为用逗号隔开的 key=value 对的列表。

供应商专有的配置信息

Oracle
如果错误地配置了 Oracle 数据源,您可能会在日志输出里看到这样的错误:
WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
要解决这个错误,请确保 recovery-username 里配置的 Oracle 用户可以访问恢复所需的表。下面是安装了 Oracle bug 5945463 补丁的 Oracle 11g 或 Oracle 10g R2 实例的正确 Grant SQL 语句。
GRANT SELECT ON sys.dba_pending_transactions TO recovery-username;
GRANT SELECT ON sys.pending_trans$ TO recovery-username;
GRANT SELECT ON sys.dba_2pc_pending TO recovery-username;
GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
如果你使用了 11g 以前的 Oracle 11 版本,请将最后的 EXECUTE 语句修改为:
	GRANT EXECUTE ON sys.dbms_system TO recovery-username;
PostgreSQL
关于启用 pepared (也就是 XA)事务的说明请阅读 PostgreSQL 文档。PostgreSQL 的 JDBC 驱动的 8.4-701 版本在 org.postgresql.xa.PGXAConnection 里有一个程序错误,它在某些情况下会中断恢复。在更新的版本里我们会修复这个问题。
MySQL
根据 http://bugs.mysql.com/bug.php?id=12161,XA 事务恢复在 MySQL 5 的某些版本里无法运行。MySQL 6.1 里已解决了这个问题。详情请参考 bug URL 或 MySQL 文档。
IBM DB2
IBM DB2 期望 XAResource.recover 方法只是在应用服务器发生崩溃或故障后重启时的重同步阶段才被调用。这是 DB2 实现里的设计问题,超出了本文档的范畴。

6.5. 数据源安全性

6.5.1. 关于数据源安全性

数据源安全性的首选方案是使用安全域或密码阀。下面是它们各自的例子。关于更多的信息,请参考:

例 6.5. 安全域示例

<security>
   <security-domain>mySecurityDomain</security-domain>
</security>

例 6.6. 密码阀示例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>

6.6. 数据源配置

6.6.1. 数据源参数

表 6.3. XA 和非 XA 数据源共用的数据源参数

参数 描述
jndi-name 数据源的唯一 JNDI 名称。
pool-name 数据源的管理池的名称。
enabled 是否启用数据源
use-java-context
是否绑定数据源到全局 JNDI。
spy
启用 JDBC 层的 spy 功能。这会将所有 JDBC 通讯记录到数据源。logging-category 参数也必须设置为 org.jboss.jdbc
use-ccm 启用缓存连接管理者。
new-connection-sql 当连接被添加到连接池时会执行的 SQL 语句。
transaction-isolation
下列值之一:
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-delimiter 用于高可用性(HA)群集数据库的 connection-url 的分隔符。
url-selector-strategy-class-name 实现 org.jboss.jca.adapters.jdbc.URLSelectorStrategy 接口的类。
security
包含设置安全性的子元素。请参考 表 6.8 “安全性参数”
validation
包含设置有效性的子元素。 请参考 表 6.9 “用于检验的参数”
timeout
包含设置超时的子元素。请参考 表 6.10 “超时参数”
statement
包含设置语句的子元素。请参考 表 6.11 “语句参数”

表 6.4. Non-XA 数据源参数

参数 描述
jta 为非 XA 数据源启动 JTA 集成。不适用于 XA 数据源。
connection-url JDBC 驱动连接的 URL。
driver-class JDBC 驱动类的全限定名。
connection-property
传递给 Driver.connect(url,props) 方法的任意连接属性。每个 connection-property 都指定一个字符串/值对。属性名称来自元素名称,而值来自元素的内容。
pool
包含设置池的子元素。请参考 表 6.6 “non-XA 和 XA 数据源公用的池参数”

表 6.5. XA 数据源参数

参数 描述
xa-datasource-property
分配给 XADataSource 类实现的属性。通过 name=value 指定。如果存在 setName 格式的 setter 方法,这个属性将通过调用 setName(value) 格式的 setter 方法来设置。
xa-datasource-class
javax.sql.XADataSource 实现的全限定名。
driver
对包含 JDBC 驱动的 classloader 模块的唯一引用。有效的格式是 driverName#majorVersion.minorVersion
xa-pool
recovery
包含设置恢复的子元素。请参考 表 6.12 “恢复参数”

表 6.6. non-XA 和 XA 数据源公用的池参数

参数 描述
min-pool-size 池里可保留的连接的最小数量。
max-pool-size 池里可保留的连接的最大数量。
prefill 是否预先填充连接池。空的元素表示 true 值。默认为 false
use-strict-min pool-size 是否是严格规定的。默认为 false
flush-strategy
在发生错误时是否冲刷池。有效值为:
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
默认值为 FailingConnectionOnly
allow-multiple-users 指定是否有多个用户将通过 getConnection(user, password) 访问数据源,且内部池类型是否应该计入在内。

表 6.7. XA 池参数

参数 描述
is-same-rm-override javax.transaction.xa.XAResource.isSameRM(XAResource) 类是否返回 truefalse
interleaving 是否启用 XA 连接工厂的 interleaving。
no-tx-separate-pools 是否为每个上下文创建单独的子池。对于 Oracel 数据源来说这是必需的,它不允许 XA 连接既在 JTA 内部又在外部使用。
pad-xid 是否拆分 Xid。
wrap-xa-resource
是否将 XAResource 包裹在 org.jboss.tm.XAResourceWrapper 实例里。

表 6.8. 安全性参数

参数 描述
user-name 创建新连接使用的用户名。
password 创建新连接使用的密码。
security-domain 非 XA 数据源参数
reauth-plugin 定义一个重验证插件以用于重新验证物理连接。

表 6.9. 用于检验的参数

参数 描述
valid-connection-checker
提供 SQLException.isValidConnection(Connection e) 方法来检验连接的 org.jboss.jca.adaptors.jdbc.ValidConnectionChecker 接口的实现。异常表示连接已被销毁。它覆盖了 check-valid-connection-sql 参数(如果存在)。
check-valid-connection-sql 检查池连接有效性的 SQL 语句。当从池里获取受管连接进行使用时它会被调用。
validate-on-match
指定当连接工厂试图对给定的集合匹配受管连接时是否执行连接级别的检验。
我们通常不会同时指定 validate-on-matchbackground-validation 为 true。但客户在使用连接前必须进行检验时则需要 Validate-on-match。这个参数默认为 true。
background-validation
指定连接在背景线程上进行检验。背景检验不和 validate-on-match 一起使用是一种性能优化。如果 validate-on-match 为 true 时,使用 background-validation 可能导致冗余的检查。背景检验可能会让用户用到有问题的连接(连接在返回给客户和检验扫描之间可能会出现问题),所以客户应用程序必须考虑到这种可能性。
background-validation-millis 背景检验运行的时间(毫秒)。
use-fast-fail
如果为 true,在第一次尝试时如果连接无效则失败。默认为 false
stale-connection-checker
提供 Boolean isStaleConnection(SQLException e) 方法的 org.jboss.jca.adapters.jdbc.StaleConnectionChecker 实例。如果这个方法返回 true,异常将包裹在 org.jboss.jca.adapters.jdbc.StaleConnectionExceptionSQLException 的子类)里。
exception-sorter
提供 Boolean isExceptionFatal(SQLException e) 方法的 org.jboss.jca.adapters.jdbc.ExceptionSorter 实例。这个方法检验异常是否作为 connectionErrorOccurred 消息传播到所有的 javax.resource.spi.ConnectionEventListener 实例上。

表 6.10. 超时参数

参数 描述
use-try-lock 使用 tryLock() 而不是 lock()。在指定秒数内试图获取锁,而不是在锁不可用时立即失败。默认值为 60 秒。如果超时为 5 分钟,则应设置 <use-try-lock>300</use-try-lock>
blocking-timeout-millis 等待连接时阻塞的最长时间(毫秒)。超过这个时间后,异常将被抛出。这只是在等待连接许可时阻塞,如果创建新连接花费很长时间并不会抛出异常。默认值为 30000,也就是 30 秒。
idle-timeout-minutes
在空闲连接关闭前的最长等待时间(分钟)。实际的最长时间取决于 idleRemover 扫描时间,它是任何池的最小 idle-timeout-minutes 的一半。
set-tx-query-timeout
是否根据事务超时前剩下的时间设置查询超时。如果没有事务存在则使用任何配置好的查询超时时间。默认为 false
query-timeout 查询的超时时间(秒)。默认是无超时。
allocation-retry 在抛出异常前,重新尝试分配连接的次数。默认为 0,异常将在第一次失败时抛出。
allocation-retry-wait-millis
在重新分配连接前应等待的时间(毫秒)。默认值是 5000,也就是 5 秒。
xa-resource-timeout
如果为非零值,这个值将传递给 XAResource.setTransactionTimeout 方法。

表 6.11. 语句参数

参数 描述
track-statements
当连接返回池且语句返回到 prepared 语句缓存时是否检测未关闭的语句。如果为 false,则不会对语句进行追踪。

有效值

  • true: : 对语句和结果集进行跟踪,如果没有关闭则提示警告。
  • false: 对语句和结果集都不进行跟踪。
  • nowarn: 语句将被跟踪但不会发出警告。这是默认设置。
prepared-statement-cache-size 每个连接的 prepared 语句的个数,存在于 Least Recently Used (LRU) 缓存里。
share-prepared-statements
是否两次请求相同的底层 prepared 语句而不关闭它。默认是 false

表 6.12. 恢复参数

参数 描述
recover-credential 安全域用于恢复的用户名/密码对。
recover-plugin
用于恢复的 org.jboss.jca.core.spi.recoveryRecoveryPlugin 类。

6.6.2. 数据源连接 URL

表 6.13. 

数据源 数据源 URL
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

6.6.3. 数据源扩展

数据源部署可以使用 JDBC 资源适配器里的几个扩展来改进连接检验,并检查异常是否应该重新建立连接。这些扩展是:

表 6.14. 数据源扩展

数据源扩展 配置参数 描述
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> 检查 SQLException 对于抛出它的连接是否是毁灭性的
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> 将过时的 SQLExceptions 包裹在 org.jboss.jca.adapters.jdbc.StaleConnectionException
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> 检查连接是否有效,能为应用程序所用。
JBoss EAP 6 也为几个受支持的数据库实现了这些扩展。

扩展实现

通用
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.6.4. 查看数据源统计

您可以用下列命令从定义的数据源里查看 jdbcpool 的统计信息:

过程 6.10. 

  • /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
    
    /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
    

注意

确保您指定了 include-runtime=true 参数,因为所有统计都是 runtime 信息。默认值为 false

6.6.5. 数据源统计

核心统计信息

下表包含受支持的数据源核心统计信息列表:

表 6.15. 核心统计信息

名称 描述
ActiveCount
活动连接的数量。每个连接都是正在被应用程序使用或是在池里备用。
AvailableCount
池里可用连接的数量。
AverageBlockingTime
获取池里排他锁时阻塞的平均时间。单位为毫秒。
AverageCreationTime
创建连接所花费的平均时间。单位为毫秒。
CreatedCount
创建的连接数量。
DestroyedCount
销毁的连接数量。
InUseCount
正在使用的连接的数量。
MaxCreationTime
创建连接所花费的最长时间。单位为毫秒。
MaxUsedCount
使用的连接的最大数目。
MaxWaitCount
同一时间等待连接的请求的最大数目。
MaxWaitTime
等待池里排他锁所花费的最长时间。
TimedOut
超时连接的数量。
TotalBlockingTime
等待池里排他锁总共所花费的时间。单位为毫秒。
TotalCreationTime
创建连接总共所花费的时间。单位为毫秒。
WaitCount
需要等待连接的请求的数量。
JDBC 统计信息

下表包含受支持的数据源 JDBC 统计信息列表:

表 6.16. JDBC 统计信息

名称 描述
PreparedStatementCacheAccessCount
语句缓存被访问的次数。
PreparedStatementCacheAddCount
添加到语句缓存里的语句数量。
PreparedStatementCacheCurrentSize
目前缓存在语句缓存里的 prepared 和可调用的语句的数量。
PreparedStatementCacheDeleteCount
从缓存里丢弃的语句的数量。
PreparedStatementCacheHitCount
语句在缓存里被使用的次数。
PreparedStatementCacheMissCount
对缓存里语句的请求无法被满足的次数。

6.7. 示例数据源

6.7.1. PostgreSQL 数据源示例

例 6.7. 

下面的例子是一个 PostgreSQL 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 PostgreSQL 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.2. PostgreSQL XA 数据源示例

例 6.8. 

下面的例子是一个 PostgreSQL XA 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 PostgreSQL XA 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.3. MySQL 数据源示例

例 6.9. 

下面的例子是一个 MySQL 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 MySQL 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.4. MySQL XA 数据源示例

例 6.10. 

下面的例子是一个 MySQL XA 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 MySQL XA 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.5. Oracle 数据源示例

注意

在 Oracle 数据源 10.2 之前的版本里,<no-tx-separate-pools/> 参数是必需的,因为非事务性和事务性连接的混合可能导致错误。对于某些应用程序来说,这个参数已不再是必需的了。

例 6.11. 

下面的例子是一个 Oracle 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 Oracle 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.6. Oracle XA 数据源示例

注意

在 Oracle 数据源 10.2 之前的版本里,<no-tx-separate-pools/> 参数是必需的,因为非事务性和事务性连接的混合可能导致错误。对于某些应用程序来说,这个参数已不再是必需的了。

重要

下面的设置必须应用于访问 Oracle XA 数据源的用户以使 XA 恢复可以正常操作。user 的值是连接 JBoss 到 Oracle 的用户:
  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user; (If using Oracle 10g R2 (patched) or Oracle 11g)
    OR
    GRANT EXECUTE ON sys.dbms_system TO user; (If using an unpatched Oracle version prior to 11g)

例 6.12. 

下面的例子是一个 Oracle XA 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 Oracle XA 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.7. Microsoft SQLServer 数据源示例

例 6.13. 

下面的例子是一个 Microsoft SQLServer 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
</datasources>

下面是用于上面的 Microsoft SQLServer 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.8. Microsoft SQLServer XA 数据源示例

例 6.14. 

下面的例子是一个 Microsoft SQLServer XA 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 Microsoft SQLServer XA 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.9. IBM DB2 数据源示例

例 6.15. 

下面的例子是一个 IBM DB2 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 IBM DB2 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.10. IBM DB2 XA 数据源示例

例 6.16. 

下面的例子是一个 IBM DB2 XA 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">false</config-property>
        <config-property name="IsValidOverride">false</config-property>
        <config-property name="EnableClose">false</config-property>
      </recover-plugin>
    </recovery>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 IBM DB2 XA 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
    <resource-root path="db2jcc_license_cisuz.jar"/>
    <resource-root path="db2jcc_license_cu.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.11. Sybase 数据源示例

例 6.17. 

下面的例子是一个 Sybase 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 Sybase 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.12. Sybase XA 数据源示例

例 6.18. 

下面的例子是一个 Sybase XA 数据源配置。这个数据源已被启用,用户已经添加并已设置了检验选项。
<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

下面是用于上面的 Sybase XA 数据源的 module.xml 文件示例。
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

第 7 章 配置模块

7.1. 简介

7.1.1. 模块

模块是用于类加载和依赖关系管理的类的逻辑组。JBoss EAP 6 使用两种模块类型,有时称为静态和动态模块。然而,这两者的区别只是它们打包的方式。所有模块都提供相同的功能。
静态模块
静态模块是在应用服务器的 EAP_HOME/modules/ 目录里进行预定义的。每个子目录都代表一个模块并包含一个或多个 JAR 文件和配置文件(module.xml)。模块的名称是在 module.xml 文件里定义的。所有应用服务器提供的 API 都是作为静态模块提供的,包括 Java EE API 以及其他 API(如 Jboss Logging)。

例 7.1. module.xml 文件示例

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.1.15.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

模块名 com.mysql 应该匹配这个模块的目录结构。
如果许多使用相同第三方库的应用程序部署在相同的服务器上,那么创建自定义静态模块就很有用。不是将这些库捆绑到每个应用程序,而是由 JBoss 管理员创建和安装包含这些库的模块。然后应用程序就可以声明对自定义静态模块的显性依赖关系。
动态模块
应用服务器为每个 JAR 或 WAR 部署(或 EAR 里的子部署)创建和加载动态模块。动态模块的名称源自部署的归档的名称。因为部署是作为模块加载的,它们可以配置依赖关系并被其他部署作为依赖关系使用。
模块只有在需要时才会加载。这通常只在具有显性或隐性依赖关系的应用程序部署时发生。

7.1.2. 全局模块

全局模块(Global Module)是 JBoss EAP 6 作为每个应用程序的依赖关系而提供的模块。将任何模块添加到应用服务器的全局模块列表里都可以使其成为全局模块,你并不需要修改模块。

7.1.3. 模块的依赖关系

模块依赖关系是某个模块要求另外一个模块的类行使功能的声明。模块可以声明对多个模块的依赖关系。当应用服务器加载一个模块时,模块类加载器将解析该模块的依赖关系并从每个依赖关系中添加类到 class path 里。如果无法找到指定的依赖关系,这个模块将加载失败。
部署的应用程序(JAR 和 WAR)将被加载为动态模块并使用依赖关系来访问 JBoss EAP 6 提供的 API。
依赖关系的类型有两种:explicit(显性的)和 implicit(隐性的)
显性依赖关系是由开发人员声明的。静态的模块可以在 modules.xml 文件里声明依赖关系。动态模块可以在 MANIFEST.MF 或 jboss-deployment-structure.xml 里声明依赖关系。
显性的依赖关系可以指定为可选项。加载可选依赖关系失败不会造成模块无法加载。然而,如果依赖关系之后变成可用的,它不会被添加到模块的 classpath 里。当加载模块时,依赖关系必须是可用的。
隐性的依赖关系在某些条件满足或在部署里发现元数据时自动由应用服务器添加。JBoss EAP 6 附带的 Java EE 6 API 是通过检测部署里的隐性依赖关系而添加的模块的示例。
我们可以配置部署排除特定的隐性依赖关系。这是通过 jboss-deployment-structure.xml 部署描述符文件来完成的。这常常发生在当应用程序捆绑某个版本的库文件,而应用服务器将试图将其添加为隐性依赖关系的时候。
模块的 Class path 包含自己的类及其直接的依赖关系。模块无法访问其中一个依赖关系的依赖关系类。然而,模块可以指定导出某个显性的依赖关系。导出的依赖关系将提供给任何依赖于导出它的模块的模块。

例 7.2. 模块依赖关系

模块 A 依赖于模块 B 而模块 B 依赖于模块 C。模块 A 可以访问模块 B 的类,模块 B 可以访问模块 C 的类。模块 A 无法访问模块 C 的类。
  • 模块 A 声明了对模块 C 的显性依赖关系,或者
  • 模块 B 导出它对模块 C 的依赖关系。

7.1.4. 子部署类加载器的隔离

EAR 里的每个子部署都是一个动态模块,它有自己的类加载器。在默认情况下,子部署可以访问其他子部署的资源。
如果子部署不应该访问其他子部署的资源(要求严格的子部署隔离),那么就可以启用隔离。

7.2. 对所有的部署禁用子部署模块隔离(Sub-Deployment Module Isolation)

这个任务展示了服务器管理员在应用服务期上如何禁用子部署模块隔离。这会影响到所有的部署。

警告

这个任务要求您编辑服务器的 XML 配置文件。编辑前这个服务器必须先暂停,这是临时措施,最终版本的管理工具将会支持这种配置。
  1. 停止服务器

    暂停 JBoss EAP 服务器。
  2. 打开服务器配置文件

    在文本编辑器里打开服务器配置文件。
    对于受管域和独立服务器这个文件是不同的。此外也可能使用非默认的位置和文件名称。对于受管域和独立服务器,默认的配置文件分别是 domain/configuration/domain.xmlstandalone/configuration/standalone.xml
  3. 定位 EE 子系统配置

    在配置文件里找到 EE 子系统配置元素。配置文件的 <profile> 元素包含了几个子系统元素。EE 子系统元素的命名空间是 urn:jboss:domain:ee:1.0
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.0" />
    
       ...
    默认的配置有一个自闭合的标签,但自定义的配置可能有单独的开和合标签(里面可能还有其他元素),如:
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
  4. 如果需要则替换自闭合的标签

    如果 EE Subsystem 元素是一个单个的自闭合标签,那么请用合适的开和合标签来替换,如:
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
  5. 添加 ear-subdeployments-isolated 元素

    ear-subdeployments-isolated 元素添加为 EE Subsystem 元素的子元素并添加 false 内容,如:
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
  6. 期待服务器

    重新启动 JBoss EAP 服务器以使用新的配置运行。
结果:

服务器现在对于所有部署都禁用了 Subdeployment Module Isolation。

7.3. 添加模块到所有部署里

这个任务展示了 JBoss 管理员如何定义全局模块列表。

前提条件

  1. 您必须知道要配置为全局模块的模块的名称。关于 JBoss EAP 6 附带的静态模块的列表,请参考 第 7.4.1 节 “包括的模块”。如果这个模块是另外一个部署,请参考 第 7.4.2 节 “动态模块命名” 来确定模块名。

过程 7.1. 添加模块到全局模块列表里

  1. 进入 EE Subsystem 面板。
      • 独立模式

        从控制台的顶部选择 Profile 标签页。
      • 域模式

        1. 从控制台的顶部选择 Profiles 标签页。
        2. 从左上角的下拉菜单里选择合适的配置集。
        3. 展开控制台左侧的 Subsystems 菜单。
    1. 从控制台左侧的菜单里选择 ContainerEE
  2. 点击 Subsystem Defaults 部分的 Add 按钮。Create Module 对话框将会出现。
  3. 输入模块名以及模块 slot(可选)。
  4. 点击 Save 按钮来添加新的全局模块,或者点击 Cancel 链接中止。
    • 如果您点击了 Save 按钮,对话框将关闭而指定的模块将被添加到全局模块列表里。
    • 如果您点击了 Cancel,对话框将关闭且不会保存任何修改。
结果

添加到全局模块列表的模块将作为依赖关系添加到每个部署里。

7.4. 参考

7.4.1. 包括的模块

  • asm.asm
  • ch.qos.cal10n
  • com.google.guava
  • com.h2database.h2
  • com.sun.jsf-impl
  • com.sun.jsf-impl
  • com.sun.xml.bind
  • com.sun.xml.messaging.saaj
  • gnu.getopt
  • javaee.api
  • javax.activation.api
  • javax.annotation.api
  • javax.api
  • javax.ejb.api
  • javax.el.api
  • javax.enterprise.api
  • javax.enterprise.deploy.api
  • javax.faces.api
  • javax.faces.api
  • javax.inject.api
  • javax.interceptor.api
  • javax.jms.api
  • javax.jws.api
  • javax.mail.api
  • javax.management.j2ee.api
  • javax.persistence.api
  • javax.resource.api
  • javax.rmi.api
  • javax.security.auth.message.api
  • javax.security.jacc.api
  • javax.servlet.api
  • javax.servlet.jsp.api
  • javax.servlet.jstl.api
  • javax.transaction.api
  • javax.validation.api
  • javax.ws.rs.api
  • javax.wsdl4j.api
  • javax.xml.bind.api
  • javax.xml.jaxp-provider
  • javax.xml.registry.api
  • javax.xml.rpc.api
  • javax.xml.soap.api
  • javax.xml.stream.api
  • javax.xml.ws.api
  • jline
  • net.sourceforge.cssparser
  • net.sourceforge.htmlunit
  • net.sourceforge.nekohtml
  • nu.xom
  • org.antlr
  • org.apache.ant
  • org.apache.commons.beanutils
  • org.apache.commons.cli
  • org.apache.commons.codec
  • org.apache.commons.collections
  • org.apache.commons.io
  • org.apache.commons.lang
  • org.apache.commons.logging
  • org.apache.commons.pool
  • org.apache.cxf
  • org.apache.httpcomponents
  • org.apache.james.mime4j
  • org.apache.log4j
  • org.apache.neethi
  • org.apache.santuario.xmlsec
  • org.apache.velocity
  • org.apache.ws.scout
  • org.apache.ws.security
  • org.apache.ws.xmlschema
  • org.apache.xalan
  • org.apache.xerces
  • org.apache.xml-resolver
  • org.codehaus.jackson.jackson-core-asl
  • org.codehaus.jackson.jackson-jaxrs
  • org.codehaus.jackson.jackson-mapper-asl
  • org.codehaus.jackson.jackson-xc
  • org.codehaus.woodstox
  • org.dom4j
  • org.hibernate
  • org.hibernate.envers
  • org.hibernate.infinispan
  • org.hibernate.validator
  • org.hornetq
  • org.hornetq.ra
  • org.infinispan
  • org.infinispan.cachestore.jdbc
  • org.infinispan.cachestore.remote
  • org.infinispan.client.hotrod
  • org.jacorb
  • org.javassist
  • org.jaxen
  • org.jboss.as.aggregate
  • org.jboss.as.appclient
  • org.jboss.as.cli
  • org.jboss.as.clustering.api
  • org.jboss.as.clustering.common
  • org.jboss.as.clustering.ejb3.infinispan
  • org.jboss.as.clustering.impl
  • org.jboss.as.clustering.infinispan
  • org.jboss.as.clustering.jgroups
  • org.jboss.as.clustering.service
  • org.jboss.as.clustering.singleton
  • org.jboss.as.clustering.web.infinispan
  • org.jboss.as.clustering.web.spi
  • org.jboss.as.cmp
  • org.jboss.as.connector
  • org.jboss.as.console
  • org.jboss.as.controller
  • org.jboss.as.controller-client
  • org.jboss.as.deployment-repository
  • org.jboss.as.deployment-scanner
  • org.jboss.as.domain-add-user
  • org.jboss.as.domain-http-error-context
  • org.jboss.as.domain-http-interface
  • org.jboss.as.domain-management
  • org.jboss.as.ee
  • org.jboss.as.ee.deployment
  • org.jboss.as.ejb3
  • org.jboss.as.embedded
  • org.jboss.as.host-controller
  • org.jboss.as.jacorb
  • org.jboss.as.jaxr
  • org.jboss.as.jaxrs
  • org.jboss.as.jdr
  • org.jboss.as.jmx
  • org.jboss.as.jpa
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate.infinispan
  • org.jboss.as.jpa.openjpa
  • org.jboss.as.jpa.spi
  • org.jboss.as.jpa.util
  • org.jboss.as.jsr77
  • org.jboss.as.logging
  • org.jboss.as.mail
  • org.jboss.as.management-client-content
  • org.jboss.as.messaging
  • org.jboss.as.modcluster
  • org.jboss.as.naming
  • org.jboss.as.network
  • org.jboss.as.osgi
  • org.jboss.as.platform-mbean
  • org.jboss.as.pojo
  • org.jboss.as.process-controller
  • org.jboss.as.protocol
  • org.jboss.as.remoting
  • org.jboss.as.sar
  • org.jboss.as.security
  • org.jboss.as.server
  • org.jboss.as.standalone
  • org.jboss.as.threads
  • org.jboss.as.transactions
  • org.jboss.as.web
  • org.jboss.as.webservices
  • org.jboss.as.webservices.server.integration
  • org.jboss.as.webservices.server.jaxrpc-integration
  • org.jboss.as.weld
  • org.jboss.as.xts
  • org.jboss.classfilewriter
  • org.jboss.com.sun.httpserver
  • org.jboss.common-core
  • org.jboss.dmr
  • org.jboss.ejb-client
  • org.jboss.ejb3
  • org.jboss.iiop-client
  • org.jboss.integration.ext-content
  • org.jboss.interceptor
  • org.jboss.interceptor.spi
  • org.jboss.invocation
  • org.jboss.ironjacamar.api
  • org.jboss.ironjacamar.impl
  • org.jboss.ironjacamar.jdbcadapters
  • org.jboss.jandex
  • org.jboss.jaxbintros
  • org.jboss.jboss-transaction-spi
  • org.jboss.jsfunit.core
  • org.jboss.jts
  • org.jboss.jts.integration
  • org.jboss.logging
  • org.jboss.logmanager
  • org.jboss.logmanager.log4j
  • org.jboss.marshalling
  • org.jboss.marshalling.river
  • org.jboss.metadata
  • org.jboss.modules
  • org.jboss.msc
  • org.jboss.netty
  • org.jboss.osgi.deployment
  • org.jboss.osgi.framework
  • org.jboss.osgi.resolver
  • org.jboss.osgi.spi
  • org.jboss.osgi.vfs
  • org.jboss.remoting3
  • org.jboss.resteasy.resteasy-atom-provider
  • org.jboss.resteasy.resteasy-cdi
  • org.jboss.resteasy.resteasy-jackson-provider
  • org.jboss.resteasy.resteasy-jaxb-provider
  • org.jboss.resteasy.resteasy-jaxrs
  • org.jboss.resteasy.resteasy-jsapi
  • org.jboss.resteasy.resteasy-multipart-provider
  • org.jboss.sasl
  • org.jboss.security.negotiation
  • org.jboss.security.xacml
  • org.jboss.shrinkwrap.core
  • org.jboss.staxmapper
  • org.jboss.stdio
  • org.jboss.threads
  • org.jboss.vfs
  • org.jboss.weld.api
  • org.jboss.weld.core
  • org.jboss.weld.spi
  • org.jboss.ws.api
  • org.jboss.ws.common
  • org.jboss.ws.cxf.jbossws-cxf-client
  • org.jboss.ws.cxf.jbossws-cxf-factories
  • org.jboss.ws.cxf.jbossws-cxf-server
  • org.jboss.ws.cxf.jbossws-cxf-transports-httpserver
  • org.jboss.ws.jaxws-client
  • org.jboss.ws.jaxws-jboss-httpserver-httpspi
  • org.jboss.ws.native.jbossws-native-core
  • org.jboss.ws.native.jbossws-native-factories
  • org.jboss.ws.native.jbossws-native-services
  • org.jboss.ws.saaj-impl
  • org.jboss.ws.spi
  • org.jboss.ws.tools.common
  • org.jboss.ws.tools.wsconsume
  • org.jboss.ws.tools.wsprovide
  • org.jboss.xb
  • org.jboss.xnio
  • org.jboss.xnio.nio
  • org.jboss.xts
  • org.jdom
  • org.jgroups
  • org.joda.time
  • org.junit
  • org.omg.api
  • org.osgi.core
  • org.picketbox
  • org.picketlink
  • org.python.jython.standalone
  • org.scannotation.scannotation
  • org.slf4j
  • org.slf4j.ext
  • org.slf4j.impl
  • org.slf4j.jcl-over-slf4j
  • org.w3c.css.sac
  • sun.jdk

7.4.2. 动态模块命名

所有部署都被 JBoss EAP 6 加载为模块并按照下列规格进行命名。
  1. WAR 和JAR 文件的部署是用下列格式命名的:
     deployment.DEPLOYMENT_NAME 
    例如,inventory.warstore.jar 的模块名分别是deployment.inventory.wardeployment.store.jar
  2. EAR 里的子部署是用下列格式命名的:
     deployment.EAR_NAME.SUBDEPLOYMENT_NAME 
    例如,accounts.ear 里的 reports.war 子部署的模块名将是 deployment.accounts.ear.reports.war

第 8 章 全局 Valve

8.1. 关于 Valve

Valve 是一个 Java 类,它在 Servlet 过滤器之前插入到应用程序的请求处理管道里。Valve 可以在将请求传递或执行其他处理(如验证或取消请求)之前修改请求。Valve 通常和应用程序打包在一起。
6.1.0 和以后的版本支持全局 Valve。

8.2. 关于全局 Valve

全局 Valve 是插入到应用程序的请求处理管道里的 Valve。在 JBoss EAP 6 里 Valve 可以通过打包或安装为静态模块来成为全局 Valve。全局 Valve 是在 web 子系统里配置的。
只有 6.1.0 和以后的版本支持全局 Valve。

8.3. 关于 Authenticator Valve

Authenticator Valve 是一个验证请求的凭证的 Valve。它是 org.apache.catalina.authenticator.AuthenticatorBase 的一个子类并重写了 authenticate() 方法。
它可以用于实现其他的验证模式。

8.4. 安装 Global Valve

全局 Valve 必须打包和安装为 JBoss EAP 6 里的静态模块。这个任务展示了如何安装模块。

预备条件:

  • Valve 必须已被创建且打包在 JAR 文件里。
  • 必须为这个模块创建一个 module.xml 文件。
    关于 module.xml 文件的例子,请参考 第 7.1.1 节 “模块”

过程 8.1. 安装全局模块(Global Module)

  1. 创建模块安装目录

    在应用服务器的 modules 目录里必须创建一个安装模块的目录。
    EAP_HOME/modules/system/layers/base/MODULENAME/main
    $ mkdir -P /usr/share/jboss/modules/system/layers/base/MyValveModule/main
  2. 复制文件

    复制 JAR 和 module.xml 文件到步骤 1 创建的目录里。
    $ cp MyValves.jar modules.xml /usr/share/jboss/modules/system/layers/base/MyValveModule/main
模块里声明的 Valve 类现在可在 web 子系统里进行配置。

8.5. 配置全局 Valve

全局 Valve 可以在 web 子系统里启用和配置。这是用 JBoss CLI 工具来完成的。

过程 8.2. 配置全局 Valve

  1. 启用 Valve

    使用 add 操作添加新的 Valve 条目。
    /subsystem=web/valve=VALVENAME:add(module="MODULENAME",class-name="CLASSNAME")
    您需要指定下列值:
    • VALVENAME,用来引用应用程序配置里的 valve 的名称。
    • MODULENAME,包含要配置的 Valve 的模块。
    • CLASSNAME,模块里专有 valve 的类名。
    /subsystem=web/valve=clientlimiter:add(module="clientlimitermodule",class-name="org.jboss.samplevalves.restrictedUserAgentsValve")
  2. 可选:指定参数

    如果 Valve 有配置参数,请用 add-param 操作进行指定。
    /subsystem=web/valve=testvalve:add-param(param-name="NAME", param-value="VALUE")
    /subsystem=web/valve=testvalve:add-param(
       param-name="restricteduseragents", 
       param-value="^.*MS Web Services Client Protocol.*$"
    )
Valve 已为所有部署的应用程序启用且配置好。

第 9 章 应用程序部署

9.1. 关于应用程序部署

JBoss EAP 6 带有一系列的应用程序部署和配置选项以满足管理和开发环境的需要。对于管理员而言,管理控制台和管理 CLI 提供了理想的图形化和命令行界面来管理产品环境里的应用程序部署。对于开发人员而言,应用程序部署测试选项包含了高度可配置的文件系统部署扫描器、对 IDE 如 JBoss Developer Studio 的使用及通过 Maven 进行部署和卸载。

9.2. 用管理控制台进行部署

9.2.1. 在管理控制台里管理应用程序的部署

通过管理控制台部署应用程序可为你提供易于使用的图形界面。你可以马上看到部署到服务器或组里的应用程序,而且你可以按照需要禁用或删除内容库里的应用程序。

9.2.2. 使用管理控制台部署应用程序

过程 9.1. 用管理控制台部署应用程序

  1. 进入管理控制台的 Manage Deployments 面板

    1. 从控制台的顶部选择 Runtime 标签页。
    2. 展开 DomainStandalone 菜单(如果还没展开)。
    3. 从控制台左侧的菜单里选择 Manage Deployments 选项。
  2. 部署应用程序

    部署方法会根据部署到独立服务器还是受管域而有所不同。
    • 部署到独立服务器实例

      Available Deployment Content 表显示所有可用的应用程序部署及其状态。
      1. 启用独立服务器实例里的应用程序

        点击 Deployments 表里的 Enable 按钮来启用应用程序部署。
      2. 确认

        点击 confirm 按钮来确认应用程序将在服务器实例上启用。
    • 部署到受管域

      Deployment Content 部分包含一个 Content Repository 表,它显示所有可用的应用程序部署及其状态。
      1. 启用受管域里的应用程序

        点击 Content Repository 表里的 Add 按钮。
      2. 选择服务器组

        选择您要添加应用程序的服务器组并点击 Save 按钮继续。
      3. 确认

        点击 Server Group Deployments 标签页来查看 Server Groups 表。您的应用程序现在已部署到所选的服务器组了。
结果

应用程序部署在相关的服务器或服务器组。

9.2.3. 用管理控制台下载应用程序

过程 9.2. 用管理控制台卸载应用程序

  1. 进入管理控制台的 Manage Deployments 面板

    1. 从控制台的顶部选择 Runtime 标签页。
    2. 展开 DomainStandalone 菜单(如果还没展开)。
    3. 从控制台左侧的菜单里选择 Manage Deployments 选项。
  2. 卸载应用程序

    卸载方法会根据部署到独立服务器还是受管域而有所不同。
    • 从独立服务器实例卸载应用程序

      Available Deployment Content 表显示所有可用的应用程序部署及其状态。
      1. 禁用独立服务器实例里的应用程序

        点击 Deployments 表里的 Disable 按钮来禁用应用程序部署。
      2. 确认您要禁用这个应用程序

        点击 confirm 按钮来确认应用程序将在服务器实例上禁用。
    • 从受管域里卸载

      Deployment Content 部分包含一个 Content Repository 标签页,Available Deployment Content 显示所有可用的应用程序部署及其状态。
      1. 禁用受管域里的应用程序

        点击 Server Group 标签页来查看服务器组以及部署的应用程序的状态。
      2. 选择服务器组

        点击 Server Group 表里的服务器来卸载应用程序。
      3. 从所选的服务器里禁用应用程序

        点击 disable 按钮来禁用所选服务器里的应用程序。
      4. 确认您要禁用这个应用程序

        点击 confirm 按钮来确认应用程序将在服务器实例上禁用。
      5. 对剩下的服务器组重复这些步骤

        按需要对其他服务器组重复这些步骤。Deployments 表里可以确认每个服务器组里的应用程序的状态。
结果

应用程序已从相关的服务器或服务器组里卸载。

9.3. 用管理 CLI 进行部署

9.3.1. 在管理 CLI 里管理应用程序的部署

通过管理 CLI 部署应用程序可让您用简单的命令行来创建和运行部署脚本。您可以使用脚本来配置专有的应用程序部署和管理场景。您既可以管理独立服务器实例里单个服务器的部署状态,也可以管理受管域里整个服务器网络。

9.3.2. 用管理 CLI 在受管域里部署应用程序

过程 9.3. 在受管域里部署应用程序

  • 运行 deploy 命令

    在管理 CLI 里,输入 deploy 命令及应用程序部署的位置。如要部署到所有的服务器组,可以使用 --all-server-groups 参数。
    [domain@localhost:9999 /] deploy /path/to/test-application.war --all-server-groups
    • 或者,用 --server-groups 参数定义部署的专有服务器组。
      [domain@localhost:9999 /] deploy /path/to/test-application.war --server-groups=server_group_1,server_group_2
    请注意,成功的部署不会在 CLI 里产生任何输出。
结果

指定的应用程序现在已部署在受管域的服务器组里了。

9.3.3. 用管理 CLI 卸载受管域里的应用程序

过程 9.4. 卸载受管域里的应用程序

  • 运行 undeploy 命令

    在管理 CLI 里,输入 undeploy 命令及应用程序部署的文件名。如果要从应用程序原来部署过的所有服务器组里卸载这个应用程序,可以使用 --all-relevant-server-groups 参数。
    [domain@localhost:9999 /]undeploytest-application.war--all-relevant-server-groups
    请注意,成功的卸载不会在 CLI 里产生任何输出。
结果

指定的应用程序已经卸载了。

9.3.4. 用管理 CLI 在独立服务器里部署应用程序

过程 9.5. 在独立服务器里部署应用程序

  • 运行 deploy 命令

    在管理 CLI 里,输入 deploy 命令及应用程序部署的位置。
    [standalone@localhost:9999 /] deploy /path/to/test-application.war
    请注意,成功的部署不会在 CLI 里产生任何输出。
结果

指定的应用程序已部署在独立服务器里了。

9.3.5. 用管理 CLI 卸载独立服务器里的应用程序

过程 9.6. 卸载独立服务器里的应用程序

  • 运行 undeploy 命令

    在管理 CLI 里,输入 undeploy 命令及应用程序部署的文件名。
    [standalone@localhost:9999 /] undeploy test-application.war
    请注意,成功的卸载不会在 CLI 里产生任何输出。
结果

指定的应用程序已经卸载了。

9.4. 用部署扫描器进行部署

9.4.1. 在部署扫描器(Deployment Scanner)里管理应用程序的部署

通过部署扫描器将应用程序部署到独立服务器实例里允许你以适合快速开发周期的方式构建和测试应用程序。你可以配置部署扫描器以适合不同应用程序类型的部署频率和行为。

9.4.2. 用部署扫描器部署应用程序到独立服务器实例

总结

这个任务展示了用部署扫描器部署应用程序到独立服务器实例的方法。如 第 9.1 节 “关于应用程序部署” 所述,这个方法是为了方便开发人员而保留的,对于产品环境下的管理我们推荐管理控制台和管理 CLI 方法。

过程 9.7. 使用部署扫描器部署应用程序

  1. 复制内容到 deployment 目录

    复制应用程序文件到 EAP_HOME/standalone/deployments/ 里的 deployment 目录。
  2. 部署扫描模式

    应用程序部署分为自动和手动部署扫描模式。
    • 自动扫描

      部署扫描器获取文件夹状态的变动并创建一个 第 9.4.5 节 “对部署扫描器 Marker 文件的引用” 主题里定义的 marker 文件。
    • 手动部署

      部署扫描器需要一个 marker 文件来触发部署过程。下面的例子使用了 Unix touch 命令来创建一个新的 .dodeploy 文件。

      例 9.1. 用 touch 命令进行部署

      [user@host bin]$ touch$EAP_HOME/standalone/deployments/example.war.dodeploy
结果

应用程序文件部署到了应用服务器里。deployment 目录里创建了一个 marker 文件以表示部署成功,且应用程序在管理控制台里被标记为 Enabled

例 9.2. 在部署后 deployment 目录包含了下列内容

example.war
example.war.deployed

9.4.3. 用部署扫描器卸载独立服务器实例的应用程序

总结

这个任务展示了用部署扫描器卸载独立服务器实例的应用程序的方法。如 第 9.1 节 “关于应用程序部署” 所述,这个方法是为了方便开发人员而保留的,对于产品环境下的管理我们推荐管理控制台和管理 CLI 方法。

注意

部署扫描器不应该和其他用于应用程序管理的部署方法一起使用。通过管理控制台从应用服务器删除的应用程序将从 runtime 删除而不会影响 marker 文件及 deployment 目录里包含的应用程序。要最小化意外重部署或其他错误的风险,在产品环境里请使用管理 CLI 和管理控制台。

过程 9.8. 用下列方法之一卸载应用程序

  • 卸载应用程序

    有两种方法可以卸载应用程序,这取决于您是否想从 deployment 目录删除应用程序还是只修改它的部署状态。
    • 通过删除 marker 文件进行卸载

      删除已部署的应用程序的 example.war.deployed marker 文件来触发部署扫描器从 runtime 卸载应用程序。
      结果
      部署扫描器卸载应用程序并创建一个 example.war.undeployed marker 文件。应用程序仍保留在 deployment 目录里。
    • 通过删除应用程序进行卸载

      从 deployment 目录删除应用程序来触发部署扫描器从 runtime 卸载应用程序。
      结果
      部署扫描器卸载应用程序并创建一个 filename.filetype.undeployed marker 文件。应用程序现在不会出现在 deployment 目录里了。
结果

应用程序文件从应用服务器里卸载且不会出现在管理服务器的 Deployments 屏幕上了。

9.4.4. 用部署扫描器在独立服务器实例里重新部署应用程序

总结

这个任务展示了用部署扫描器重新部署应用程序到独立服务器实例的方法。如 第 9.1 节 “关于应用程序部署” 所述,这个方法是为了方便开发人员而保留的,对于产品环境下的管理我们推荐管理控制台和管理 CLI 方法。

过程 9.9. 在独立服务器里重新部署应用程序

  • 重新部署应用程序

    重新部署用部署扫描器部署的应用程序有三种可能的方法。这些方法可以触发部署扫描器来启动部署循环,您可以按个人喜好进行选择。
结果

应用程序被重新部署。

9.4.5. 对部署扫描器 Marker 文件的引用

Marker 文件

Marker 文件是部署扫描器子系统的一部分。这些文件标记独立服务器的 deployment 目录里的应用程序的状态。Marker 文件具有和应用程序相同的名称,其后缀则表示部署的状态。下表定义了每个 marker 文件的类型及响应。

例 9.4. Marker 文件示例

下面的例子展示了用于成功部署的 testapplication.war 应用程序的实例的 marker 文件。
testapplication.war.deployed

表 9.1. Marker 文件类型定义

文件名后缀 来源 描述
.dodeploy 用户生成 表示内容应该部署到 runtime 或从 runtime 卸载。
.skipdeploy 用户生成 禁用应用程序的自动部署。用作禁止展开内容的自动部署的临时方法,阻止不完整的内容进入应用环境。它可以用于压缩的内容,扫描器会检测压缩内容的进度并等待完成。
.isdeploying 系统生成 表示部署的初始化。当部署过程完成时,Marker 文件将被删除。
.deployed 系统生成 表示内容已经被部署。如果文件被删除,这些内容将被卸载。
.failed 系统生成 表示部署失败。Marker 文件包含关于失败原因的信息。如果 Marker 文件被删除,这些内容将再次对于自动部署可见。
.isundeploying 系统生成 表示对删除 .deployed 文件的响应。完成后其内容将被卸载且 marker 文件将被自动删除。
.undeployed 系统生成 表示内容已被卸载。Marker 文件的删除对内容重部署没有影响。
.pending 系统生成 表示部署说明将被发送到有检测的问题还未解决的服务器。这个 marker 文件充当全局部署 road-block。当这个条件存在时,扫描器不会指引服务器部署或卸载任何其他内容。

9.4.6. 对部署扫描器属性的引用

部署扫描器包含下列开放给管理 CLI 且可用 write-attribute 进行配置的属性。关于配置选项的更多信息,请参考 第 9.4.8 节 “用管理 CLI 配置部署扫描器”

表 9.2. 部署扫描器属性

名称 描述 类型 默认值
auto-deploy-exploded 允许自动部署展开内容而无需 .dodeploy marker 文件。我们仅推荐用于基本的部署场景,以防止在开发人员或操作系统进行修改时发生展开的应用程序的部署。 布尔值(Boolean) False
auto-deploy-xml 允许自动部署 XML 内容而无需 .dodeploy marker 文件。 布尔值(Boolean) True
auto-deploy-zipped 允许自动部署压缩内容而无需 .dodeploy marker 文件。 布尔值(Boolean) True
deployment-timeout 部署扫描器在取消部署前允许尝试部署的时间。 Long 600
path 定义要扫描的实际的文件系统路径。如果指定了 relative-to 属性,path 值将充当该目录或路径的相对路径。 String deployments
relative-to 对在服务器配置 XML 文件的 paths 部分定义的文件系统路径的引用。 String jboss.server.base.dir
scan-enabled 允许在启动时及每隔 scan-interval 自动扫描应用程序。 布尔值(Boolean) True
scan-interval 扫描资料库的时间间隔(毫秒)。小于 1 的值表示扫描器只有在启动时才操作。 Int 5000

9.4.7. 配置部署扫描器

我们可以用管理控制台或管理 CLI 配置部署扫描器。您可以创建一个新的部署扫描器或者管理现有的扫描器属性。这些包括扫描间隔、部署文件夹的位置、触发部署的应用程序文件类型。

9.4.8. 用管理 CLI 配置部署扫描器

总结

虽然有多个方法可以配置部署扫描器,管理 CLI 可以用批处理脚本或实时开放和修改属性。您可以用 read-attributewrite-attribute 全局命令行操作修改部署扫描器的行为。关于部署扫描器属性的更多信息,请参考 第 9.4.6 节 “对部署扫描器属性的引用”

部署扫描器是 JBoss EAP 6 的一个子系统,您可以在 standalone.xml 里查看它。
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
</subsystem>

过程 9.10. 配置部署扫描器

  1. 确定要配置的部署扫描器属性

    通过管理 CLI 配置部署描述符要求您首先开放正确的属性名。您可以在根节点上用 read-resources 操作来实现,或者用 cd 命令来修改子节点。您也可以用 ls 命令显示这个级别的属性。
    • read-resource 操作开放部署扫描器的属性

      请使用 read-resource 操作来开放默认部署扫描器资源定义的属性。
      [standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource
      {
          "outcome" => "success",
          "result" => {
              "auto-deploy-exploded" => false,
              "auto-deploy-xml" => true,
              "auto-deploy-zipped" => true,
              "deployment-timeout" => 600,
              "path" => "deployments",
              "relative-to" => "jboss.server.base.dir",
              "scan-enabled" => true,
              "scan-interval" => 5000
          }
      }
      
    • ls 命令开放部署扫描器属性

      请使用 ls 命令和 -l 可选参数来显示包含子系统节点、值和类型的结果。您可以输入ls --help 来学习关于 ls 命令及其参数的更多内容。关于管理 CLI 里帮助菜单的详情,请参考 第 3.5.5 节 “用管理 CLI 获取帮助”
      [standalone@localhost:9999 /] ls -l /subsystem=deployment-scanner/scanner=default
      ATTRIBUTE            VALUE                 TYPE    
      auto-deploy-exploded false                 BOOLEAN 
      auto-deploy-xml      true                  BOOLEAN 
      auto-deploy-zipped   true                  BOOLEAN 
      deployment-timeout   600                   LONG    
      path                 deployments           STRING  
      relative-to          jboss.server.base.dir STRING  
      scan-enabled         true                  BOOLEAN 
      scan-interval        5000                  INT
      
  2. write-attribute 操作配置部署扫描器

    在您确定了要修改的属性的名称后,请使用 write-attribute 来指定属性名称和写入的新值。下面的例子都运行在子节点级别,可以通过 cd 命令访问,并开放默认扫描器节点的 Tab 完成和修改。
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    
    1. 启用展开内容的自动部署

      请使用 write-attribute 命令来禁用展开的 应用程序内容的自动部署。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true)
      {"outcome" => "success"}
      
    2. 禁用 XML 内容的自动部署

      请使用 write-attribute 命令来禁用 XML 应用程序内容的自动部署。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false)     
      {"outcome" => "success"}
      
    3. 禁用压缩内容的自动部署

      请使用 write-attribute 命令来禁用压缩的应用程序内容的自动部署。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false)
      {"outcome" => "success"}
      
    4. 配置路径属性

      请使用 write-attribute 操作来修改路径属性,用新的路径名替换 newpathname 以被部署扫描器监控。请注意,服务器需要重启以使修改生效。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname)            
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
      
    5. 配置相对路径属性

      请使用 write-attribute 操作来修改对 XML 配置文件里路径部分定义的文件路径的相对引用。请注意,服务器将需要重启以使修改生效。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
      
    6. 禁用部署扫描器

      请使用 write-attribute 命令并将 scan-enabled 设为 false 来禁用部署扫描器。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false)        
      {"outcome" => "success"}
      
    7. 修改扫描间隔

      请使用 write-attribute 操作来修改扫描间隔(5000 到 10000 毫秒)。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
      
结果

您对配置的修改已保存到部署扫描器里。

9.5. 用 Maven 进行部署

9.5.1. 用 Maven 管理应用程序部署

通过 Maven 部署应用程序允许您将部署周期合并为现有部署工作流的一部分。

9.5.2. 用 Maven 部署应用程序

总结

本节展示了用 Maven 部署应用程序的方法。下面的例子使用了 JBoss EAP 6 Quickstarts 里的 jboss-as-helloworld.war 应用程序。helloworld 项目包含了一个初始化了 jboss-as-maven-plugin 的 POM 文件。这个插件提供了在应用服务器里部署和卸载应用程序的简单操作。

过程 9.11. 用 Maven 部署应用程序

  1. 在终端会话里运行 Maven deploy 命令

    打开终端会话并进入包含 Quickstart 例程的目录里。
  2. 运行 Maven deploy 命令来部署应用程序。如果应用程序已经运行,它将被重新部署。
    [localhost]$ mvn package jboss-as:deploy
  3. 确认应用程序部署

    • 在终端窗口里查看结果

      通过在终端窗口里查看操作日志可以确认部署。

      例 9.5. 通过 Maven 确认 Helloworld 应用程序

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 3 seconds
      [INFO] Finished at: Mon Oct 10 17:22:05 EST 2011
      [INFO] Final Memory: 21M/343M
      [INFO] ------------------------------------------------------------------------
      
      
    • 在服务器终端窗口里查看结果

      部署在活动应用程序服务器实例的状态流里也可以确认。

      例 9.6. 通过应用服务器确认 Helloworld 应用程序

      17:22:04,922 INFO  [org.jboss.as.server.deployment] (pool-1-thread-3) Content added at location /home/username/EAP_HOME/standalone/data/content/2c/39607b0c8dbc6a36585f72866c1bcfc951f3ff/content
      17:22:04,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "jboss-as-helloworld.war"
      17:22:04,954 INFO  [org.jboss.weld] (MSC service thread 1-3) Processing CDI deployment: jboss-as-helloworld.war
      17:22:04,973 INFO  [org.jboss.weld] (MSC service thread 1-2) Starting Services for CDI deployment: jboss-as-helloworld.war
      17:22:04,979 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
      17:22:05,051 INFO  [org.jboss.web] (MSC service thread 1-2) registering web context: /jboss-as-helloworld
      17:22:05,064 INFO  [org.jboss.as.server.controller] (pool-1-thread-3) Deployed "jboss-as-helloworld.war"
结果

应用程序已部署到应用服务器里。

9.5.3. 用 Maven 卸载应用程序

总结

本节展示了用 Maven 卸载应用程序的方法。下面的例子使用了 JBoss EAP 6 Quickstarts 里的 jboss-as-helloworld.war 应用程序。helloworld 项目包含了一个初始化了 jboss-as-maven-plugin 的 POM 文件。这个插件提供了在应用服务器里部署和卸载应用程序的简单操作。

过程 9.12. 用 Maven 卸载应用程序

  1. 在终端会话里运行 Maven deploy 命令

    打开终端会话并进入包含 Quickstart 例程的目录里。

    例 9.7. 进入 helloworld 应用程序目录

    [localhost]$ cd /path/to/EAP_Quickstarts/helloworld
    
  2. 运行 Maven undeploy 命令来卸载应用程序。
    [localhost]$ mvn jboss-as:undeploy
  3. 确认应用程序已卸载

    • 在终端窗口里查看结果

      通过在终端窗口里查看操作日志可以确认卸载。

      例 9.8. 通过 Maven 确认 Helloworld 应用程序

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] Building JBoss AS Quickstarts: Helloworld
      [INFO]    task-segment: [jboss-as:undeploy]
      [INFO] ------------------------------------------------------------------------
      [INFO] [jboss-as:undeploy {execution: default-cli}]
      [INFO] Executing goal undeploy for /home/username/EAP_Quickstarts/helloworld/target/jboss-as-helloworld.war on server localhost (127.0.0.1) port 9999.
      Oct 10, 2011 5:33:02 PM org.jboss.remoting3.EndpointImpl <clinit>
      INFO: JBoss Remoting version 3.2.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.Xnio <clinit>
      INFO: XNIO Version 3.0.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.nio.NioXnio <clinit>
      INFO: XNIO NIO Implementation Version 3.0.0.Beta2
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011
      [INFO] Final Memory: 11M/212M
      [INFO] ------------------------------------------------------------------------
      
      
    • 在服务器终端窗口里查看结果

      卸载在活动应用程序服务器实例的状态流里也可以确认。

      例 9.9. 通过应用服务器确认 Helloworld 应用程序

           
      17:33:02,334 INFO  [org.jboss.weld] (MSC service thread 1-3) Stopping weld service
      17:33:02,342 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment jboss-as-helloworld.war in 15ms
      17:33:02,352 INFO  [org.jboss.as.server.controller] (pool-1-thread-5) Undeployed "jboss-as-helloworld.war"
      
      
结果

从服务器服务器里卸载了应用程序。

9.6. 控制 JBoss EAP 6 里部署应用程序的顺序

JBoss EAP 6 提供了服务器启动时对部署顺序的细颗粒度控制。您可以启用多个 EAR 文件里的严格的部署顺序以及重启后的持久化顺序。

过程 9.13. 控制 JBoss EAP 6.0.X 里部署的顺序

  1. 创建在服务器启动/停止时按顺序部署和卸载应用程序的 CLI 脚本。
  2. CLI 也支持批模式,它允许您将命令和操作分组并作为一个原子单元执行。如果有一个命令或操作运行失败,该批模式里所有其他已成功执行的命令或操作将进行回滚。

过程 9.14. 控制 JBoss EAP 6.1.X 里部署的顺序

EAP 6.1.X 里有一个名为 Inter Deployment Dependencies 的新功能,它允许您在顶层部署间声明依赖关系。
  1. app.ear/META-INF 文件夹里创建一个 jboss-all.xml 文件(如果没有),这里的 app.ear 是依赖于另外一个之前部署的应用程序的归档。
  2. 如下所示,在这个文件里创建一个 jboss-deployment-dependencies 条目。请注意,在下面的列表里,framework.ear 是应该在 app.ear 之前部署的依赖关系应用程序归档。
    <jboss umlns="urn:jboss:1.0">
      <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
        <dependency name="framework.ear" />
      </jboss-deployment-dependencies>
    </jboss>
    

9.7. 部署描述符覆盖

EAP 6.1.x 里有一个新的功能,它允许您在运行时覆盖部署描述符。deployment overlay 代表了归档里的一个规则集文件,它必须被覆盖。它也提供到应该替代被覆盖文件的新文件的链接。如果在部署归档里没有出现被覆盖的文件,那它会被添加回部署里。

过程 9.15. 用管理 CLI 覆盖部署描述符

下面的步骤假设您已经有一个部署的应用程序 app.war,你想用 /home/user/web.xml 下的 web.xml 覆盖它的 WEB-INF/web.xml 文件。
  1. 添加一个部署重叠并添加内容。您可以以下列两种方式来进行:
    • 使用 DRM 树

      1. /deployment-overlay=myoverlay:add
      2. /deployment-overlay=myoverlay/content=WEB-INF\/web.xml:add(content={url=file:///home/user/web.xml})
        如果您愿意,您可以用第二个语句添加更多的内容规则。
    • 使用 convenience 模式

      deployment-overlay add --name=myoverlay --content=WEB-INF/web.xml=/home/user/web.xml
  2. 链接重叠到部署归档

    • deployment-overlay link --name=myoverlay --deployments=app.war
      你必须指定用逗号隔开的多个归档名称。
    • /deployment-overlay=myoverlay/deployment=app.war:add
      请注意,部署归档并不需要存在于服务器上。您可以指定这个名称,但不将其链接到实际的部署。
  3. 重部署应用程序

    /deployment=app.war:redeploy

第 10 章 保护 JBoss EAP 6

10.1. 关于安全子系统

安全子系统为 JBoss EAP 6 里的所有安全功能提供了基础结构。多数配置元素都几乎不需要修改。唯一需要修改的配置元素是是否使用 deep-copy-subject-mode。此外,你可以配置系统范围的安全属性。多数的配置都和安全域(Security Domain)相关。
Deep Copy 模式

如果 Deep Copy 模式被禁用(默认),复制安全数据结构会产生一个对原始结构的引用,而不是复制整个数据结构。这个行为效率更高,但在具有相同标识符的多个线程通过冲刷或登出操作清除主题时容易受数据损坏的影响。

只要被标记为可克隆的(cloneable),Deep Copy 模式会导致数据结构及相关数据的完整复制。这是更多线程安全的,但效率更低。
系统范围的安全属性

你可以设置系统范围的安全属性,它们应用在 java.security.Security 类。

安全域

安全域(Security Domain)是一系列 Java 验证和授权服务(Java Authentication and Authorization Service,JAAS)的声明式安全配置,一个或多个应用程序用它来控制验证、授权、审计和映射。有三个默认的安全域:jboss-ejb-policyjboss-web-policyother。你也可以按照应用程序的需要创建安全域。

10.2. 关于安全子系统的结构

安全子系统是在受管域或独立服务器的配置文件里配置的。多数配置元素可以用基于 web 的管理控制台或基于控制台的管理 CLI 来配置。下面是一个安全子系统配置的 XML 片段。

例 10.1. 安全子系统配置示例

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>		
		

<security-management><subject-factory><security-properties> 元素没有出现在默认配置里。从 JBoss EAP 6.1 开始已启用了 <subject-factory><security-properties> 元素。

10.3. 配置安全子系统

你可以用管理 CLI 或基于 web 的管理控制台来配置安全子系统。
安全子系统里的每个顶级元素都包含关于安全配置不同方面的信息。关于安全子系统配置的例子,请参考 第 10.2 节 “关于安全子系统的结构”
<security-management>
这部分内容覆盖了安全子系统的高层行为。每个设置都是可选的。除了 Deep Copy 模式,须该这些设置的任何一个都是不寻常的。
选项 描述
deep-copy-subject-mode
指定是否复制或链接安全令牌以用于额外的线程安全。
authentication-manager-class-name
指定一个要使用的其他的 AuthenticationManager 实现的类名。
authorization-manager-class-name
指定一个要使用的其他的 AuthorizationManager 实现的类名。
audit-manager-class-name
指定一个要使用的其他的 AuditManager 实现的类名。
identity-trust-manager-class-name
指定一个要使用的其他的 IdentityTrustManager 实现的类名。
mapping-manager-class-name
指定一个要使用的 MappingManager 实现的类名。
<subject-factory>
主题工厂(Subject factory)控制主题实例的创建。它可以使用验证管理者来检验调用者。主题工厂的主要用途是为了 JCA 组件建立主题。你通常不需要修改它。
<security-domains>
保存多个安全域的容器元素。安全域可能包含关于验证、授权、映射、审计模块以及 JASPI 验证和 JSSE 配置的信息。你的应用程序可以指定一个安全域来管理它的安全信息。
<security-properties>
包含在 java.security.Security 类上设置的属性的名字和值。

10.4. 关于 Deep Copy Subject 模式

如果 Deep Copy 主题模式被禁用(默认),复制安全数据结构会产生一个对原始结构的引用,而不是复制整个数据结构。这个行为效率更高,但在具有相同标识符的多个线程通过冲刷或登出操作清除主题时容易受数据损坏的影响。
只要被标记为可克隆的(cloneable),Deep Copy 主题模式会导致数据结构及相关数据的完整复制。这是更多线程安全的,但效率更低。
Deep Copy Subject 模式是作为安全子系统的一部分来配置的。

10.5. 启用 Deep Copy Subject 模式

你可以通过基于 Web 的管理控制台或管理 CLI 来启用 Deep Copy 安全模式。

过程 10.1. 通过管理控制台启用 Deep Copy 安全模式

  1. 登录到管理控制台。

    管理控制台通常可通过类似 http://127.0.0.1:9990/ 的 URL 进行访问,请根据需要调整。
  2. 受管域:选择合适的配置集。

    在受管域里,安全子系统是针对每个配置集进行配置的,而且你可以在每个子系统里独立地启用或禁用 Deep Copy 安全模式。
    要选择配置集,请点击控制台右上角的 Profiles 标签,然后在左上角的 Profile 选择你要修改的配置集家。
  3. 打开 Security Subsystem 配置菜单。

    展开管理控制台右侧的 Security 菜单,然后点击 Security Subsystem 链接。
  4. 修改 deep-copy-subject-mode 值。

    点击 Edit 按钮。选定 Deep Copy Subjects: 复选框来启用 Deep Copy Subject 模式。
使用管理 CLI 启用 Deep Copy Subject 模式

如果你想通过管理 CLI 来启用这个选项,请使用下列命令。

例 10.2. 受管域

/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

例 10.3. 独立服务器

/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

10.6. 安全域

10.6.1. 关于安全域

安全域是 JBoss EAP 6 安全子系统的一部分。所有的安全配置现在都由受管域的域控制器或独立服务器来集中管理了。
安全域由验证、授权、安全映射和审计的配置组成。它实现了 Java 验证和授权服务(Java Authentication and Authorization Service,JAAS) 声明式安全性。
验证指的是检验用户的身份。按照安全性术语,这个用户被称为 principal。虽然验证的授权是不同的,系统包含的许多验证模块也可以处理授权。
authorization 是一个安全策略,服务器靠它来决定已验证的用户是否具有访问系统或操作里某些权利或资源的权限。按照安全性术语,它也常被称为角色。
安全映射(Security mapping)指的是将信息传递给应用程序之前在 principal、角色或属性里添加、修改、删除信息的能力。。
审计管理者允许你配置提供者模块(provider modules)来控制报告安全事件的方式。
如果你使用安全域,你可以从应用程序删除所有的专有安全配置。这允许你集中地修改安全参数。受益于这种配置结构的一个常见场景是在测试和产品环境间移动应用程序。

10.6.2. 关于 Picketbox

Picketbox 是基础的安全框架,它为运行在 JBoss EAP 6 里的 Java 应用程序提供了验证、授权、审计和映射能力。它用单一的配置在单一的框架里提供了这些能力:

10.6.3. 关于验证

验证指的是确定一个主题并检验标识的真实性。最常见的验证机制是用户名和密码的组合。其他常见的机制使用共享密钥、智能卡或指纹。按照 Java EE 的声明安全性,成功验证的结果被称为 principal。
JBoss EAP 6 使用一个可插拔的验证模块系统,它提供灵活性以及与机构里已使用的验证系统的集成性。每个安全域都包含一个或多个配置好的验证模块。每个模块都包含其他的配置参数来自定义其行为。配置验证子系统的最简单的方法是通过基于 web 的管理控制台。
验证和授权不同,虽然他们经常联系在一起。许多包含的验证模块也可以处理授权。

10.6.4. 配置安全域的验证

要配置安全域的验证,请登录到管理控制台并遵循下列步骤。

过程 10.2. 为安全域设置验证

  1. 打开安全域的详细视图。

    点击管理控制台由上角的 Profiles 标签。在受管域里,从 Profile 视图左上角的 Profile 选择框里选择要修改的配置集。点击左侧的 Security 并点击展开菜单里的 Security Domains。点击你要编辑的安全域的 View 链接。
  2. 进入验证子系统配置。

    如果还未选择的话,点击视图顶部的 Authentication 标签。
    配置区域分成两部分:Login ModulesDetails。登录模块是配置的基本单元。安全域可以包含多个登录模块,每个都包括几个属性和选项。
  3. 添加一个验证模块。

    点击 Add 按钮来添加一个 JAAS 验证模块。输入相关的内容。Code 是模块的类名。Flags 控制模块如何和相同安全域里的其他验证模块交互。
    对标签的解释

    Java EE 6 规格提供了安全域的标签的解释。下面的列表来自 http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA。关于更消息的信息,请参考这个文档。

    标签 详情
    required
    登录模块是验证成功所必需的。如果成功或失败,验证都仍会继续处理登录模块列表。
    requisite
    登录模块是验证成功所必需的。如果成功,验证将继续处理登录模块列表。如果失败,控制权马上返回给应用程序(验证不会继续处理登录模块列表)。
    sufficient
    登录模块不是验证成功所必需的。如果成功,控制权马上返回给应用程序(验证不会继续处理登录模块列表)。如果失败,验证将继续处理登录模块列表。
    optional
    登录模块不是验证成功所必需的。如果成功或失败,验证都仍会继续处理登录模块列表。
    在你添加了模块时,你可以通过屏幕上的 Details 里的 Edit 按钮修改它的 CodeFlags。请确保选择了 Attributes 标签页。
  4. 可选的:添加或删除模块选项。

    如果你需要在模块里添加选项,请点击 Login Modules 列表里的条目,并在 Details 页面里选择 Module Options 标签页。点击 Add 按钮,并提供这个选项的键和值。你可以用 Remove 按钮来删除选项。
结果

你的验证模块已添加至安全域,且马上可为使用安全域的应用程序所用。

jboss.security.security_domain 模块选项

在默认情况下,安全域里定义的每个登录模块都会自动添加一个 jboss.security.security_domain 模块选项。这个选项会给检查是否只定义了已知选项的登录模块带来问题。IBM Kerberos 登录模块 com.ibm.security.auth.module.Krb5LoginModule 就是其中之一。

你可以通过在启动 JBoss EAP 时设置系统属性为 true 来禁用添加这个模块选项的行为。请添加下列内容到你的启动参数里。
-Djboss.security.disable.secdomain.option=true
你也可以用基于 web 的管理控制台来设置这个属性。在独立服务器里,你可以在配置文件的 Profile 部分来设置系统属性。在受管域里,你可以对每个服务器组设置系统属性。

10.6.5. 关于授权

授权是一个基于身份来赋予或拒绝对资源访问的机制。它作为一系列可以赋予 principal 的声明式安全角色来实现。
JBoss EAP 使用一个模块化系统来配置授权。每个安全域都可以获得一个或多个授权策略。每个策略都有一个定义自身行为的基本模块。它也可以通过特定的标记和属性来配置。配置授权子系统的最简单的方法是使用基于 web 的管理控制台。
授权不同于验证,它通常在验证之后发生。很多验证模块也可以处理授权。

10.6.6. 配置安全域里的授权

要配置安全域的授权,请登录到管理控制台并遵循下列步骤。

过程 10.3. 在安全域里设置授权

  1. 打开安全域的详细视图。

    点击管理控制台由上角的 Profiles 标签。在受管域里,从 Profile 视图左上角的 Profile 选择框里选择要修改的配置集。点击左侧的 Security 并点击展开菜单里的 Security Domains。点击你要编辑的安全域的 View 链接。
  2. 进入授权子系统配置。

    如果还未选择的话,点击视图顶部的 Authorization 标签。
    配置区域分成两部分:PoliciesDetails。登录模块是配置的基本单元。安全域可以包含几个授权策略,每个都包括几个属性和选项。
  3. 添加策略

    点击 Add 按钮来添加一个 JAAS 授权策略模块。输入相关的内容。Code 是模块的类名。Flags 控制模块如何和相同安全域里的其他授权模块交互。
    对标签的解释

    Java EE 6 规格提供了安全域的标签的解释。下面的列表来自 http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA。关于更消息的信息,请参考这个文档。

    标签 详情
    required
    登录模块是授权成功所必需的。如果成功或失败,授权都仍会继续处理登录模块列表。
    requisite
    登录模块是授权成功所必需的。如果成功,授权将继续处理登录模块列表。如果失败,控制权马上返回给应用程序(授权不会继续处理登录模块列表)。
    sufficient
    登录模块不是授权成功所必需的。如果成功,控制权马上返回给应用程序(授权不会继续处理登录模块列表)。如果失败,授权将继续处理登录模块列表。
    optional
    登录模块不是授权成功所必需的。如果成功或失败,授权都仍会继续处理登录模块列表。
    在你添加了模块时,你可以通过屏幕上的 Details 里的 Edit 按钮修改它的 CodeFlags。请确保选择了 Attributes 标签页。
  4. 可选的:添加、编辑或删除模块选项。

    如果你需要在模块里添加选项,点击 Login Modules 列表里的条目,并选择 Details 部分的 Module Options 标签页,并提供选项的键和值。要编辑一个已存在的选项,点击它的键来进行修改。你可以使用 Remove 按钮来删除选项。
结果

你的授权模块已添加至安全域,且马上可为使用安全域的应用程序所用。

10.6.7. 关于安全性审计

安全性审计包括触发事件,如在响应安全子系统里发生的事件而写入日志。审计机制和验证、授权、安全性映射细节都是作为安全域的一部分来配置的。
审计使用提供者模块。你可以使用内含的模块,或者实现自己的模块。

10.6.8. 配置安全审计

要配置安全域的安全审计,请登录到管理控制台并遵循下列步骤。

过程 10.4. 在安全域里设置安全审计

  1. 打开安全域的详细视图。

    点击管理控制台由上角的 Profiles 标签。在独立服务器里,标签页是 Profile。在受管域里,从 Profile 视图左上角的 Profile 选择框里选择要修改的配置集。点击左侧的 Security 并点击展开菜单里的 Security Domains。点击你要编辑的安全域的 View 链接。
  2. 进入审计子系统配置。

    如果还未选择的话,点击视图顶部的 Audit 标签。
    配置区域分成两部分:Provider ModulesDetails。提供者模块(Provider Module)是配置的基本单元。安全域可以包含多个提供者模块,每个都包括几个属性和选项。
  3. 添加一个提供者模块。

    点击 Add 按钮来添加一个提供者模块。在 Code 里输入提供者模块的类名。
    在你添加了模块时,你可以通过屏幕上的 Details 里的 Edit 按钮修改它的 Code。请确保选择了 Attributes 标签页。
  4. 检验你的模块是否可以运行

    审计模块的目的是提供一个在安全子系统里监控事件的途径。这种监控可以通过写入日志文件、电子邮件通知或其他可度量的审计机制来实现。
    例如,JBoss EAP 6 默认包含了 LogAuditProvider 模块。如果按照上面的步骤启用,这个审计模块会将安全通知写入 EAP_HOME 目录里的 log 子目录下的 audit.log 文件里。
    要检验上面的步骤是否可以在 LogAuditProvider 上下文里运行,你可以执行一个可能触发通知的动作并检查审计日志文件。
    关于安全审计提供者模块的完整列表,请参考 第 11.4 节 “包括的安全审计供应商模块”
  5. 可选的:添加、编辑或删除模块选项。

    如果你需要在模块里添加选项,点击 Modules 列表里的条目,并选择 Details 部分的 Module Options 标签页,并提供选项的键和值。要编辑一个已存在的选项,你可以使用 Remove 按钮来删除它,或者用正确的选项点击 Add 按钮再次添加它。
结果

你的安全审计模块已添加至安全域,且马上可为使用安全域的应用程序所用。

10.6.9. 关于安全性映射

安全性映射允许你在验证或授权发生后但在信息传递给应用程序之前合并验证和授权信息。其中一个例子是使用用于验证的 X509 证书,然后从证书转换 principal 为你的应用程序可以显示的逻辑名称。
你可以映射 principal(验证)、角色(授权)或凭证(非 principal 或角色的属性)。
角色映射用于在验证后对主题添加、替换或删除角色。
Principal 映射用于在验证后修改 principal。
属性映射用来从外部系统转换属性以供应用程序使用,反之亦然。

10.6.10. 在安全域里配置安全映射

要配置安全域的安全映射,请登录到管理控制台并遵循下列步骤。

过程 10.5. 在安全域里设置安全映射

  1. 打开安全域的详细视图。

    点击管理控制台由上角的 Profiles 标签。在独立服务器里,标签页是 Profile。在受管域里,从 Profile 视图左上角的 Profile 选择框里选择要修改的配置集。点击左侧的 Security 并点击展开菜单里的 Security Domains。点击你要编辑的安全域的 View 链接。
  2. 进入映射子系统配置。

    如果还未选择的话,点击视图顶部的 Mapping 标签。
    配置区域分成两部分:ModulesDetails。映射模块是配置的基本单元。安全域可以包含多个映射模块,每个都包括几个属性和选项。
  3. 添加一个模块。

    点击 Add 按钮来添加一个安全映射模块。输入模块的相关内容。Code 是模块的类名。Type 字段表示这个模块执行的映射的类型。所允许的值有 principal、role、attribute 和 credential。
    在你添加了模块时,你可以通过屏幕上的 Details 里的 Edit 按钮修改它的 CodeType。请确保选择了 Attributes 标签页。
  4. 可选的:添加、编辑或删除模块选项。

    如果你需要在模块里添加选项,点击 Modules 列表里的条目,并选择 Details 部分的 Module Options 标签页,并提供选项的键和值。要编辑一个已存在的选项,点击 Remove 标签键来删除它,并用新的值再次添加它。你可以使用 Remove 按钮来删除选项。
结果

你的安全映射模块已添加至安全域,且马上可为使用安全域的应用程序所用。

10.6.11. 在应用程序里使用安全域

概述

要在应用程序里使用安全域,首先你必须通过服务器配置文件或应用程序的描述符文件配置安全域。然后你必须添加必要的注解到使用安全域的 EJB。这个主题涵盖了在应用程序里使用安全域所需的步骤。

警告

如果应用程序不是使用验证缓存的安全域的一部分,用于该应用程序的用户验证将也可用于安全域里的其他应用程序。

过程 10.6. 配置你的应用程序以使用安全域

  1. 定义安全域

    你可以在服务器的配置文件或应用程序的描述符里定义安全域。
    • 在服务器的配置文件里配置安全域

      安全域是在服务器配置文件的 security 子系统里配置的。如果 JBoss EAP 6 实例运行在受管域里,配置文件应该是 domain/configuration/domain.xml。如果是独立服务器,则是 standalone/configuration/standalone.xml 文件。
      otherjboss-web-policyjboss-ejb-policy 都是 JBoss EAP 6 里默认提供的安全域。下面的 XML 示例是从服务器配置文件的 security 子系统里复制的。
      <subsystem xmlns="urn:jboss:domain:security:1.2">
          <security-domains>
              <security-domain name="other" cache-type="default">
                  <authentication>
                      <login-module code="Remoting" flag="optional">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                      <login-module code="RealmDirect" flag="required">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                  </authentication>
              </security-domain>
              <security-domain name="jboss-web-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
              <security-domain name="jboss-ejb-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
          </security-domains>
      </subsystem>
      
      你可以按需要用管理控制台或 CLI 配置其他的安全域。
    • 在应用程序的描述符文件里配置安全域

      安全域是在应用程序的 WEB-INF/jboss-web.xml 文件里的 <jboss-web> 元素的<security-domain> 子元素里指定的。下面的例子配置了一个名为 my-domain 的安全域。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>
      
      这只是你可以在 WEB-INF/jboss-web.xml 描述符里指定的许多设置中的一个。
  2. 在 EJB 里添加必需的注解

    你可以用 @SecurityDomain@RolesAllowed 注解在 EJB 里配置安全性。下面的 EJB 代码示例限制了具有 guest 角色的用户对 other 安全域的访问。
    package example.ejb3;
    
    import java.security.Principal;
    
    import javax.annotation.Resource;
    import javax.annotation.security.RolesAllowed;
    import javax.ejb.SessionContext;
    import javax.ejb.Stateless;
    
    import org.jboss.ejb3.annotation.SecurityDomain;
    
    /**
     * Simple secured EJB using EJB security annotations
     * Allow access to "other" security domain by users in a "guest" role.
     */
    @Stateless
    @RolesAllowed({ "guest" })
    @SecurityDomain("other")
    public class SecuredEJB {
    
       // Inject the Session Context
       @Resource
       private SessionContext ctx;
    
       /**
        * Secured EJB method using security annotations
        */
       public String getSecurityInfo() {
          // Session context injected using the resource annotation
          Principal principal = ctx.getCallerPrincipal();
          return principal.toString();
       }
    }
    关于更多的代码示例,请参考 JBoss EAP 6 Quickstarts 集里的 ejb-security quickstart,你可以在红帽的客户门户找到这些例子。

10.6.12. Java 容器授权合约(JACC)

10.6.12.1. 关于 Java 容器授权合约(JACC)

Java 容器授权合约(Java Authorization Contract for Containers,JACC)是一个定义容器和授权服务提供者之间合约的标准,它规范容器使用的提供者实现。它是由 JSR-115 定义的,你可以在 Java Community Process 网站上找到相关信息:http://jcp.org/en/jsr/detail?id=115。从 Java EE 1.3 以后,它已经是核心 Java EE 规格的一部分了。
JBoss EAP 通过安全子系统的安全性功能实现了对 JACC 的支持。

10.6.12.2. 配置 Java 容器授权合约(JACC)的安全性

要配置 JACC,你需要用正确的模块配置你的安全域,然后修改 jboss-web.xml 来包含正确的参数。
为安全域添加 JACC 支持

要为安全域添加 JACC 支持,请添加 JACC 授权策略到安全域的授权栈里,并设置 required 标记。下面是一个带有 JACC 支持的安全域的例子。然而,安全域是在管理控制台或 CLI 里,而不是直接在 XML 里配置的。

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>

配置 Web 应用程序以使用 JACC

jboss-web.xml 位于你的部署的 META-INF/WEB-INF/ 目录里,且包含用 web 容器的覆盖选项和其他的 JBoss 专有的配置。要使用启用了 JACC 的安全域,你需要包括 <security-domain> 元素并设置 <use-jboss-authorization> 元素为 true。下面的应用程序是用上面的 JACC 安全域进行正确配置的。

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>

配置 EJB 应用程序来使用 JACC

配置 EJB 使用安全域并使用 JACC 对于不同的 Web 应用程序是不同的。对于 EJB,你可以在 ejb-jar.xml 里为一个方法或方法组声明 method permissions。在 <ejb-jar> 元素里,任何子 <method-permission> 元素都包含关于 JACC 角色的信息。详情请参考示例配置。EJBMethodPermission 类是 Java EE 6 API 的一部分,且 http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html 里有相关的文档。

例 10.4. EJB 里的 JACC 方法权限示例

<ejb-jar>
  <method-permission>
    <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
    <role-name>employee</role-name>
    <role-name>temp-employee</role-name>
    <method>
      <ejb-name>EmployeeService</ejb-name>
      <method-name>*</method-name>
    </method>
  </method-permission>
</ejb-jar>
	      

你也可以通过安全域约束 EJB 的验证和授权机制,就像对 Web 应用程序所做的一样。安全域在 jboss-ejb3.xml 描述符里的 <security> 子元素里声明。除了安全域以外,你也可以指定 run-as principal,它可以修改运行 EJB 的 principal。

例 10.5. EJB 里的安全域声明示例


<security>
  <ejb-name>*</ejb-name>
  <security-domain>myDomain</security-domain>
  <run-as-principal>myPrincipal</run-as-principal>
</security>


10.6.13.  Java 容器验证 SPI(JASPI)

10.6.13.1. 关于 Java 容器验证 SPI(JASPI)的安全性

容器安全性的 Java 验证 SPI(JASPI 或 JASPIC)是一个 Java 程序的可插拔接口。它是在 Java Community Process 的 JSR-196 里定义的。关于它的规格详情,请参考 http://www.jcp.org/en/jsr/detail?id=196

10.6.13.2. 配置 Java 容器验证 SPI(JASPI)的安全性

要验证 JASPI 提供者,请添加 <authentication-jaspi> 元素到你的安全域里。其配置和标准的验证模块类似,但登录模块元素包含在 <login-module-stack> 元素里。它的配置的结构是:

例 10.6. authentication-jaspi 元素的结构

<authentication-jaspi>
	<login-module-stack name="...">
	  <login-module code="..." flag="...">
	    <module-option name="..." value="..."/>
	  </login-module>
	</login-module-stack>
	<auth-module code="..." login-module-stack-ref="...">
	  <module-option name="..." value="..."/>
	</auth-module>
</authentication-jaspi>


登录模块自身也以标准验证模块完全相同的方式进行配置。
因为基于 web 的管理控制台没有开放 JASPI 验证模块的配置,在直接添加配置到 EAP_HOME/domain/configuration/domain.xmlEAP_HOME/standalone/configuration/standalone.xml 之前你需要完全停止 JBoss EAP。

10.7. 管理接口的安全性

10.7.1. 默认的用户安全性配置

简介

在 EAP 6 里,所有的管理接口都默认是有设置安全性的。这个安全性采取两种形式:

  • 本地接口通过本地客户和服务器间的 SASL 合约设置安全性。这个安全机制基于客户访问本地文件系统的能力。这是因为访问本地文件系统会允许客户添加用户或修改配置以阻挠其他安全机制。如果对文件系统的物理访问可以实现,那么其他安全机制就是多余的。这个机制以四个步骤实现:

    注意

    即使你通过 HTTP 连接本地主机,HTTP 访问仍会视作远程的。
    1. 客户发送一条消息给服务器,它包含一个用本地 SASL 机制验证的请求。
    2. 服务器生成一个一次性的令牌,将其写入到唯一的文件里,然后发送具有完整文件路径的消息给客户。
    3. 客户从文件里读取令牌并发送给服务器,检验它是否具有对文件系统的本地访问权限。
    4. 服务器验证令牌并删除这个文件。
  • 远程客户,包括本地 HTTP 客户,使用基于区的安全性。带有使用管理接口远程配置 JBoss EAP 6 权限的默认区是 ManagementRealm。我们提供了一个脚本,允许你添加用户到这个区(或者你创建的区)。请参考《JBoss EAP 6 安装指南》Getting Started 章节。对于每个用户,用户名,hased 密码,以及区都存储在文件里。
    受管域
    EAP_HOME/domain/configuration/mgmt-users.properties
    独立服务器
    EAP_HOME/standalone/configuration/mgmt-users.properties
    即使 mgmt-users.properties 的内容都是以掩码显示的,这个文件仍必须作为敏感文件对待。我们推荐将其文件权限设置为 600,这样除了文件所有者,其他人都没有读或写的权限。

10.7.2. 高级管理接口配置概述

EAP_HOME/domain/configuration/host.xmlEAP_HOME/standalone/configuration/standalone.xml 里的管理接口配置控制主机控制器进程绑定哪些网络接口,哪种管理接口是可用的,哪种类型的验证系统用来验证每个接口上的用户。本主题讨论了如何配置管理接口以适应你的运行环境。
管理子系统由包含几个可配置属性以及下面三个可配置子元素的 <management> 元素组成。首先定义安全区和转出连接,然后再将它们作为属性应用到管理接口。
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
安全区

安全区(Security Realm)负责允许通过管理 API、管理 CLI 和基于 web 的管理控制台管理 JBoss EAP 6 的用户的验证和授权。

默认安装里有两种不同的基于文件的安全区:ManagementRealmApplicationRealm。每个安全区都使用一个 -users.properties 文件来存储用户和哈希密码,以及一个 -roles.properties 来存储用户和角色间的映射。相同也包含了对启用了 LDAP 的安全区的支持。

注意

安全区也可以用于你自己的应用程序。这里讨论的安全区是管理接口所专有的。
转出的连接

一些安全区连接至外部接口,如 LDAP 服务器。转出连接(Outbound connection)定义了如何创建这种连接。预定义的连接类型,ldap-connection,设置了连接 LDAP 服务器并验证凭证的所有必需和可选的属性。

管理接口

管理接口包含如何连接和配置 JBoss EAP 的属性。这样的信息包括命名网络接口、端口、安全区和其他关于接口的可配置信息。默认安装里包含了两个接口:

  • http-interface 是基于 web 的管理控制台的配置。
  • native-interface 是命令行管理 CLI 和类 REST 管理 API 的配置。
这三个主机管理子系统的主要可配置元素都是相关的。安全区引用转出连接,而管理接口引用安全区。
相关的信息请参考:第 10.9.1 节 “保护管理接口”

10.7.3. 关于 LDAP

轻量级目录访问协议(Lightweight Directory Access Protocol,LDAP)是一个在网络里存储和分发目录信息的协议。这个目录信息包含关于用户、硬件设备、访问角色和限制以及其他信息。
LDAP 的一些常见实现包括 OpenLDAP、Microsoft Active Directory、IBM Tivoli Directory Server、Oracle Internet Directory 等。
JBoss EAP 6 带有几个验证和授权模块,它们允许在 Web 和 EJB 应用程序里将 LDAP 服务器用于验证和授权。

10.7.4. 在管理接口里使用 LDAP 进行验证

要在管理控制台、管理 CLI 或 API 里将 LDAP 目录服务器用作验证源,你需要执行下列过程:
  1. 创建一个到 LDAP 服务器的转出连接。
  2. 创建一个启用 LDAP 的安全区。
  3. 在管理接口里引用新的安全区。
创建一个到 LDAP 服务器的转出连接

LDAP 转出连接允许下列属性:

表 10.1. LDAP 转出连接的属性

属性 要求的 描述
url
目录服务器的 URL 地址。
search-dn
授权执行搜索的用户的全限定可区分名称(Distinguished Name,DN)。
search-credentials
用户授权执行搜索的密码。
initial-context-factory
当建立连接时使用的初始上下文。默认为 com.sun.jndi.ldap.LdapCtxFactory
security-realm
为了获得建立连接时所需的已配置的 SSLContext 而引用的安全区。

例 10.7. 添加 LDAP 转出连接

这个例子用下列属性集添加了一个转出连接:
  • 搜索 DN: cn=search,dc=acme,dc=com
  • 搜索凭证: myPass
  • URL: ldap://127.0.0.1:389
第一个命令添加了安全区。
/host=master/core-service=management/security-realm=ldap_security_realm:add
第二个命令添加了 LDAP 连接。
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")
创建一个启用 LDAP 的安全区

管理接口可以针对 LDAP 服务器而不是默认的基于属性文件的安全区进行验证。LDAP 验证器将首先建立一个和远程目录服务器的连接,然后使用传入验证系统的用户名来执行搜索以找到 LDAP 记录的全限定可区分名称(Distinguished Name,DN)。新的连接将以用户的 DN 为凭证以及用户提供的密码来建立。如果这个针对 LDAP 服务器的验证成功,DN 就被证明为有效的。

LDAP 安全区需要下列配置属性和元素来执行它的功能。
connection
<outbound-connections> 里定义的连接的名称,用来连接 LDAP 目录。
base-dn
用户开始搜索的上下文的可区分的名称。
recursive
搜索是否应该在 LDAP 目录树里进行递归,或者只搜索指定的上下文。默认为 false
user-dn
保存可区分名称的用户的属性。它会被用来测试验证。默认为 dn
子元素是 username-filteradvanced-filter 中的一个。
username-filter 采用一个名为 attribute 的属性,它的值是保存用户名的 LDAP 属性的名称,如 userNamesambaAccountName
advanced-filter 采用一个名为 filter 的属性。这个属性包含以标准 LDAP 语法编写的过滤器队列。请小心地将 & 字符修改为 &amp;。下面是一个过滤器的例子:
(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
After escaping the ampersand character, the filter appears as:
(&amp;(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))

例 10.8. 代表启用了 LDAP 的安全区的 XML 片段

这个例子使用了下列参数:
  • connection - ldap_connection
  • base-dn - cn=users,dc=acme,dc=com.
  • username-filter - attribute="sambaAccountName"
<security-realm name="ldap_security_realm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
         <username-filter attribute="sambaAccountName" />
      </ldap>
  </authentication>
</security-realm>	


警告

确保不允许空 LDAP 密码是很重要的;除非你故意这么做,但这是严重的安全隐患。
EAP 6.1 包含一个用于 CVE-2012-5629 的补丁,它设置 LDAP 登录模块的 allowEmptyPasswords 选项为 false(如果它还没有被设置)。在旧的版本里,这个选项应该手动进行配置。

例 10.9. 添加 LDAP 安全区

下面的命令添加了一个安全区并针对独立服务器设置其属性。
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
应用新的安全区到管理接口里

在创建了安全区后,你需要在管理接口的配置里引用它。管理接口将使用安全区来进行 HTTP digest 验证。

例 10.10. 应用安全区到 HTTP 接口里

在配置完成后,你重启主机控制器,基于 web 的管理控制台将使用 LDAP 来验证用户。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap-security-realm)
配置受管域成员以使用 Microsoft Active Directory 来进行验证

要配置受管域里的主机根据 Microsoft Active Directory 来验证,请按照这个过程来进行,它创建了一个安全域并使用 JAAS 验证映射角色到活动目录组。这个过程是必需的,因为 Microsoft Active Directory 允许用空的密码进行绑定。这个过程防止了在应用程序平台里使用空的密码。

在执行这个过程之前,你需要知道主机控制器的名称。这个例子假定主机控制器名为 master
  1. 添加一个名为 ldap_security_realm 的新的 <security-realm>,并配置它使用 JAAS。

    下列管理 CLI 命令添加了新的安全区并设置了它的验证机制。请按需要修改主机的名称。
    /host=master/core-service=management/security-realm=ldap_security_realm/:add
    /host=master/core-service=management/security-realm=ldap_security_realm/authentication=jaas/:add(name=managementLDAPDomain)
  2. 配置 <http-interface> 以使用这个新的安全区。

    下列管理 CLI 命令配置了 HTTP 接口。
    /host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
  3. 配置 JBoss EAP,在其启动参数里添加自定义的 JAAS 配置。

    编辑 EAP_HOME/bin/domain.conf 文件。搜索 HOST_CONTROLLER_JAVA_OPTS 变量。这是你添加 JBoss EAP 启动前所需的 JVM 指令的地方。下面是这个参数的默认内容的示例:
    HOST_CONTROLLER_JAVA_OPTS="$JAVA_OPTS"
    
    添加下列指令:-Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf"
    被编辑的行类似于:
    -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf"
    
  4. 在模块选项里添加登陆模块。

    在相同的文件里,找到包含下列内容的行:
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
    修改它为下面的样子请确保不要插入任何多余的空格。
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,com.sun.security.auth.login"
    保存并关闭 domain.conf 文件。
  5. 创建将添加至 classpath 的 JAAS 配置。

    在下列位置创建一个新的文件:EAP_HOME/domain/configuration/jaas.conf
    这个文件应该包含下列内容。请按照自己的环境编辑相关的参数。
    managementLDAPDomain {
        org.jboss.security.auth.spi.LdapExtLoginModule required
            java.naming.factory.initial="com.sun.jndi.ldap.LdapCtxFactory"
            java.naming.provider.url="ldap://your_active_directory_host:389"
            java.naming.security.authentication="simple"
            bindDN="cn=Administrator,cn=users,dc=domain,dc=your_company,dc=com"
            bindCredential="password"
            baseCtxDN="cn=users,dc=domain,dc=redhat,dc=com"
            baseFilter="(&(sAMAccountName={0})(|(memberOf=cn=Domain Guests,cn=Users,dc=domain,dc=acme,dc=com)(memberOf=cn=Domain Admins,cn=Users,dc=domain,dc=acme,dc=com)))"
            allowEmptyPasswords="false"
            rolesCtxDN="cn=users,dc=domain,dc=acme,dc=com"
            roleFilter="(cn=no such group)"
            searchScope="SUBTREE_SCOPE";
    };
    
  6. 重启 JBoss EAP,你的 HTTP 接口应该使用 LDAP 服务器来验证了。

10.7.5. 禁用 HTTP 管理接口

在受管域里,你只需要访问域控制器而不是域成员服务器上的 HTTP 接口。此外,在产品服务器上,你可能会决定禁用基于 web 的管理控制台。

注意

其他服务器,如 JBoss Operations Network,也使用 HTTP 接口来操作。如果你想使用这些服务,简单地禁用管理控制台自身就可以了,你可以设置 HTTP 接口的 console-enabled 属性为 false,而无需完全禁用这个接口。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
要禁用对 HTTP 接口的访问,同时也禁用对基于 Web 的管理控制台的访问,你可以将 HTTP 接口一起删除。
如果你又想再次添加这个接口,下面的 JBoss CLI 命令允许你读取 HTTP 接口的当前内容。

例 10.11. 读取 HTTP 接口的配置

/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}
要删除 HTTP 接口,请执行下列命令:

例 10.12. 删除 HTTP 接口

/host=master/core-service=management/management-interface=http-interface/:remove
要重新启用访问,执行下列命令来重新创建带有默认值的 HTTP 接口。

例 10.13. 重新创建 HTTP 接口

/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)

10.7.6. 从默认的安全区删除无提示验证

介绍

JBoss EAP 6 的默认安装包含一个用于本地管理 CLI 用户的无提示验证(Silent Authentication)方法。这允许本地用户无需用户名或密码验证就可以访问管理 CLI。启用这个功能是为了方便,并协助本地用户无需验证就可以运行管理 CLI 脚本。它是一个非常有用的功能,特别是对本地配置的访问通常也会让用户可以添加自己的细节或禁用安全检查。

如果需要更严格的安全检查,你也可以禁用对于本地用户的无提示验证。这可以通过删除配置文件里的 security-realm 部分里的 local 来实现。这适用于独立服务器的 standalone.xml 或受管域的 host.xml。你应该只在理解了对特定服务器配置的影响后才考虑删除 local 元素。
删除无提示验证的首选方法是使用管理 CLI,在下面的例子里它直接删除了 local 元素。

例 10.14. security-realm 里的 local 元素示例

<security-realms>
    <security-realm name="ManagementRealm">
        <authentication>
            <local default-user="$local"/>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
    </security-realm>
    <security-realm name="ApplicationRealm">
        <authentication>
            <local default-user="$local" allowed-users="*"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
        <authorization>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
        </authorization>
    </security-realm>
</security-realms>

过程 10.7. 从默认的安全区删除无提示验证

  • 用管理 CLI 删除无提示验证

    按要求从管理区和应用程序区删除 local 元素。
    1. 从管理区删除 local 元素。
      • 对于独立服务器

        /core-service=management/security-realm=ManagementRealm/authentication=local:remove
      • 对于受管域

        /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
    2. 从应用程序区删除 local 元素。
      • 对于独立服务器

        /core-service=management/security-realm=ApplicationRealm/authentication=local:remove
      • 对于受管域

        /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
结果

无提示验证从 ManagementRealmApplicationRealm 里删除了。

10.7.7. 禁用对 JMX 子系统的远程访问

远程 JMX 连接性允许你触发 JDK 和应用程序管理操作。为了保护安装,请禁用这个功能。你可以通过删除远程连接配置或完全删除 JMX 子系统来实现这一点。JBoss CLI 命令引用了受管域配置里的 default 配置集。要进行修改,请修改命令的 /profile=default 部分。对于独立服务器,请完全删除命令的这个部分。

注意

在受管域里,远程连接器默认是从 JMX 子系统里删除的。如果是在部署时添加的,这个命令可供你参考。

例 10.15. 从 JMX 子系统删除远程连接器。

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove

例 10.16. 删除 JMX 子系统

如果你使用了受管域,对你使用的每个配置集都运行这个命令。
/profile=default/subsystem=jmx/:remove

10.7.8. 为管理接口配置安全区

管理接口使用安全区来控制验证和对 JBoss EAP 6 的配置机制的访问。本主题展示了如何阅读和配置安全区。这些命令使用了管理 CLI。
读取安全区的配置

这个例子展示了 ManagementRealm 安全区的默认配置。它使用了一个名为 mgmt-users.properties 的文件来保存其配置信息。

例 10.17. 默认的 ManagementRealm

	/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "authorization" => undefined,
        "server-identity" => undefined,
        "authentication" => {"properties" => {
            "path" => "mgmt-users.properties",
            "plain-text" => false,
            "relative-to" => "jboss.domain.config.dir"
        }}
    }
}
编写安全区

下面的命令创建了一个名为 TestRealm 的安全区并为相关的配置文件设置了目录。

例 10.18. 编写安全区

/host=master/core-service=management/security-realm=TestRealm/:add/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)

应用安全区到管理接口里

添加了安全区后,将其名称作为引用提供给管理接口。

例 10.19. 在管理接口里添加一个安全区

/host=master/core-service=management/management-interface=http-interface/:write-attribute(security-realm=TestRealm)

10.8. 用基于角色的访问控制来保护管理接口

10.8.1. 关于基于角色的访问控制(Role-Based Access Control,RBAC)

关于基于角色的访问控制(RBAC)是一个指定管理用户的一系列权限的机制。它允许多个用户共享管理 JBoss EAP 6.2 服务器的职责而不是拥有不受限制的权限。通过对管理用户的“职责分离”,JBoss EAP 6.2 使机构可以轻易地在个人和组之间分配职责,从而避免分配不必要的权限。这既确保了服务器和数据最大可能的安全性,也提供了配置、部署和管理的灵活性。

JBoss EAP 6.2 里的关于基于角色的访问控制是通过角色权限和约束的组合来实现的。

它提供了 7 个预定义的角色,每个都有不同的固定权限。这些预定义的角色是:Monitor、Operator、Maintainer、Deployer、Auditor、Administrator 和 SuperUser。每个管理用户都分配了一个或多个角色,这些角色指定了管理服务器时用户被允许做的事情。

10.8.2. GUI 和 CLI 的基于角色的访问控制

当启用了基于角色的访问控制(RBAC)时,根据分配的角色,用户将不能运行某些操作、读取某些资源,甚至根本无法查看管理模型的某些部分。
管理控制台

在管理控制台里,根据你分配的角色的权限,有些控件和视图是禁用的(灰色)或不可见的。

如果你没有对某个资源属性的读权限,该权限将在控制台里显示为空白。例如,多数角色无法读取数据源的用户名和密码字段。

如果你没有对某个资源属性的写权限,该权限将在资源编辑表单里显示为禁用(灰色)。如果你根本没有对这个资源的写权限,那么整个编辑表单都不会出现。

如果你没有对某个资源或属性的访问权限(就是对于你的角色来说是“不可寻址的”),那它们根本不会出现在在控制台里。其中一个例子是,访问控制系统自身在默认情况下只对一些角色可见。
管理 API

启用了 RBAC 后,使用 jboss-cli.sh 工具或直接使用 API 的用户在 API 里会遇到稍许不同的行为。

无法读取的资源和属性将从结果里过滤。如果被过滤的内容是角色可以寻址的,那么它们的名称将列为结果里 response-headers 部分的 filtered-attributes。如果它们是无法被寻址的,那根本不会被列出。

试图访问不能寻址的资源将导致 "resource not found" 错误。

如果用户试图写入或读取他们可以寻址的资源但缺乏对应的读写权限,就会返回 "Permission Denied" 。

10.8.3. 支持的验证模式

基于角色的访问控制(RBAC)可以和 JBoss EAP 6.2 附带的标准验证提供者一起使用。它们是:username/passwordclient certificatelocal user
Username/Password

用户通过用户名和密码组合根据 mgmt-users.properties 文件或 LDAP 服务器来进行检验。
Client Certificate

使用信任库。
Local User

如果服务器运行在相同的服务器上,jboss-cli.sh 将自动验证为本地用户。在默认情况下,本地用户是 SuperUser 组的成员。
不管使用哪个提供者,JBoss EAP 负责将角色分配给用户。然而,当用 mgmt-users.properties 文件或 LDAP 服务器来验证时,这些系统可以提供用户组信息。JBoss EAP 也可以使用这些信息来为用户分配角色。

10.8.4. 标准角色

JBoss EAP 6 提供 7 个预定义的用户角色:Monitor、Operator、Maintainer、Deployer、Auditor、Administrator 和 SuperUser。每个角色都有不同的一套权限以用于专有的用例。Monitor, Operator, Maintainer, Administrator 和 SuperUser 都是在前者之上构建的,其权限一次递增。Auditor 和 Deployer 角色分别与 Monitor 和 Maintainer 角色类似,但都具有一些其他的特殊权限和限制。
Monitor

充当 Monitor 角色的用户具有最小的权限且只能读取服务器的当前配置和状态。这个角色是为了那些需要跟踪和报告服务器性能的用户而设计的。

Monitor 角色既不能修改服务器配置也不能访问敏感数据或操作。
Operator

Operator 角色扩展了 Monitor 角色,它添加了修改服务器的运行时状态的能力。这表示 Operator 可以重载并关闭服务器,也可以暂停和恢复 JMS 目的地。Operator 角色对于负责应用服务器的物理或虚拟主机的用户是很理想的,他们可以确保有需要时关闭和重启服务器。

Operator 角色既不能修改服务器配置也不能访问敏感数据或操作。
Maintainer

Maintainer 角色可以查看和修改运行时状态以及除了敏感数据和操作之外的所有配置。Maintainer 角色是普通用途的角色,它不能访问敏感数据和操作。Maintainer 角色赋予用户几乎完整的管理服务器的权限,但不能访问密码和其他敏感信息。

Maintainer 角色不能访问敏感数据或操作。
Administrator

Administrator 角色具有对服务器上除了审计日志系统以外的所有资源和操作的无限制的访问权限。 Administrator 是唯一(除了 SuperUser)可以访问敏感数据和操作的角色。这个角色也可以配置访问控制系统。只有处理敏感数据或配置用户和角色时才要求 Administrator 角色。

Administrator 角色不能访问审计日志系统且不能将自己修改为 Auditor 或 SuperUser 角色。
SuperUser

SuperUser 角色没有任何限制,它可以访问任何服务器的资源和操作,包括审计日志系统。这个角色等同于以前的 JBoss EAP 6 版本(6.0 和 6.1)里的管理员用户。如果禁用了 RBAC,所有的管理用户都会拥有和 SuperUser 角色相同的权限。
Deployer

Deployer 角色具有和 Monitor 相同的角色,但它可以修改部署的配置和状态以及其他启用为应用程序资源的资源类型。
Auditor

Auditor 角色具有 Monitor 角色的所有权限,它也可以查看(但不能修改)敏感数据,且具有对审计日志系统的完全权限。Auditor 是除了 SuperUser 之外唯一能够访问审计日志系统的角色。

Auditor 角色不能修改敏感数据或资源。它只有读的权限。

10.8.5. 关于角色权限

角色具有的权限定义了它能做的事情。并非每个角色都具有每个权限。值得注意的是,SuperUser 具有所有权限,而 Monitor 的权限最小。
每个权限都可以为某个类别的资源赋予读和写权限。
这些类别是:运行时状态、服务器配置、敏感数据、审计日志和访问控制系统。
表 10.2 “角色权限矩阵” 总结了每个角色权限。

表 10.2. 角色权限矩阵

Monitor

Operator

Maintainer

Deployer

Auditor

Administrator

SuperUser

读取配置和状态

X

X

X

X

X

X

X

读取敏感数据 [2]

X

X

X

修改敏感数据 [2]

X

X

读/修改审计日志

X

X

修改运行时状态

X

X

X[1]

X

X

修改持久性配置

X

X[1]

X

X

读/修改访问控制

X

X
[1] 权限限于应用程序资源。
[2] 哪些资源被当作 "敏感数据" 是使用敏感性约束来配置的。

10.8.6. 关于约束

约束(Constraint)是对于指定资源列表的访问控制配置的集合。RBAC 系统使用了约束和角色权限的组合来确定某个用户是否可以执行管理动作。

约束分成两个类别:应用程序(application)和敏感性(sensitivity)。
应用程序约束

应用程序约束定义了可以被具有部署角色的用户访问的资源和属性集合。在默认情况下,唯一被启用的应用程序约束是 core,它包含部署、部署重叠。应用程序约束也包含在 datasources、logging、mail、messaging、naming、resource-adapters 和 security 里(默认不会启用)。这些约束允许 Deployer 用户不仅可以部署应用程序,还可以配置和维护应用程序要求的资源。

应用程序约束的配置位于管理 API 里的 /core-service=management/access=authorization/constraint=application-classification
敏感性约束

敏感性约束定义了被认为是 “敏感的”的资源的集合。敏感的资源通常是某种机密的内容,如密码,或者对服务器的操作有着重大影响的东西,如网络、JVM 配置或系统属性。访问控制系统本身也被视作敏感的资源。

唯一对敏感资源具有写权限的角色是 Administrator 和 SuperUser。Auditor 角色只能读取敏感资源。其他角色都没有访问权限。

应用程序约束的配置位于管理 API 里的 /core-service=management/access=authorization/constraint=sensitivity-classification
库表达式约束

库表达式(Vault Expression)约束定义了读/写库表达式是否被视作敏感操作。在默认情况下,这两者都是敏感操作。

库表达式约束的配置位于管理 API 的 /core-service=management/access=authorization/constraint=vault-expression

目前你不能在管理控制台配置约束。

10.8.7. 关于 JMX 和基于角色的访问控制

基于角色的访问控制以三种方式应用于 JMX:
  1. JBoss EAP 6 的 Management API 开放为 JMX Management Bean。这些 Management Bean 被称为 "core mbeans",对它们的访问和过滤同底层的 Management API 是一模一样的。
  2. JMX 子系统的写权限被配置为“敏感的”。这表示只有 Administrator 和 SuperUser 角色可以修改这个子系统。而 Auditor 角色可以读取子系统的配置。
  3. 在默认情况下,部署的应用程序和服务(non-core mbeans)注册的 Management Bean 可以被管理用户访问,但只有 Maintainer、Operator、Administrator、SuperUser 角色可以写入它。

10.8.8. 配置基于角色的访问控制

10.8.8.1. RBAC 配置任务概述

启用了 RBAC 后,只有具有 Administration 或 SuperUser 角色的用户可以查看和修改访问控制系统。
管理控制台提供了下列常见 RBAC 任务的界面:
  • 查看和配置用户分配(或排斥)了哪些角色
  • 查看和配置组分配(或排斥)了哪些角色
  • 查看每个角色的组和用户成员资格。
  • 配置每个角色默认成员资格。
  • 常见具有作用域的角色
CLI 提供了对整个访问控制系统的访问。这表示在管理控制台里可以完成的任何事情都可以在这里完成,而且你可以用 CLI 执行一些访问控制系统无法完成的任务。
在 CLI 里也可以执行下列任务:
  • 启用和禁用 RBAC
  • 修改权限组合策略
  • 配置应用程序资源和资源敏感性约束

10.8.8.2. 启用基于角色的访问控制

在默认情况下,RBAC 是被禁用的。将提供者属性从 simple 修改为 rbac 就可以启用它。你可以用 jboss-cli.sh 工具来完成,或者当服务器下线时编辑服务器配置 XML 文件。如果在运行的服务器上禁用或启用 RBAC,在生效前必须重载服务器配置。
启用后,它只能由具有 Administrator 或 SuperUser 角色的用户禁用。在默认情况下,如果jboss-cli.sh 运行在和服务器相同的主机上,它是以 SuperUser 角色运行的。

过程 10.8. 启用 RBAC

  • 要用 jboss-cli.sh 启用 RBAC,请使用访问授权资源的 write-attribute 操作来设置提供者的属性为 rbac
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }
    [standalone@localhost:9999 /] /:reload
    {
        "outcome" => "success",
        "result" => undefined
    }
    [standalone@localhost:9999 /]
    

过程 10.9. 禁用 RBAC

  • 要用 jboss-cli.sh 禁用 RBAC,请使用访问授权资源的 write-attribute 操作来设置提供者的属性为 simple
    /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }
    [standalone@localhost:9999 /] /:reload
    {
        "outcome" => "success",
        "result" => undefined
    }
    [standalone@localhost:9999 /]
    
如果服务器已下线,你可以编辑 XML 配置文件来启用或禁用 RBAC。你可以找到 management 元素下的 access-control 元素里的 provider 属性,设置为 rbac 则启用, simple 则禁用 RBAC。
<management>

        <access-control provider="rbac">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>

    </management>

10.8.8.3. 修改权限组合策略

权限组合策略(Permission Combination Policy)定义了用户被分配了多个角色时如何确定权限。它可以设置为 permissiverejecting。默认选项是 permissive
当设置为 permissive 时,如果任何角色被分配给用户,那这个角色许可的动作将会被允许执行。
而当设置为 rejecting 时,如果许可某个动作的多个角色被分配给用户,那这个动作将会被允许执行。
当策略被设置为 rejecting 时,每个用户应该只分配一个角色。当策略为 rejecting 时,具有多个角色的用户将不能使用管理控制台或 jboss-cli.sh
权限组合策略是通过设置 permission-combination-policy 属性为 permissiverejecting 来配置的。这可以用 jboss-cli.sh 工具或编辑服务器配置 XML 文件(如果服务器已下线)来完成。

过程 10.10. 设置权限组合策略

  • 使用访问授权资源的 write-attribute 操作来设置 permission-combination-policy 为所需的策略名称。
    /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
    有效的策略名称是 rejecting 和 permissive。
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization] 
    
    
如果服务器已下线,你可以编辑 XML 配置文件来修改权限组合策略。为此,你需要编辑 access-control 元素的 permission-combination-policy 属性。
<access-control provider="rbac" permission-combination-policy="rejecting">
  <role-mapping>
    <role name="SuperUser">
      <include>
        <user name="$local"/>
      </include>
    </role>
  </role-mapping>
</access-control>

10.8.9. 管理角色

10.8.9.1. 关于角色成员资格

当启用了基于角色的控制(RBAC)时,管理用户被允许做的事情是由所分配的角色来决定的。JBoss EAP 6.2 使用了基于用户和组成员资格的包含(include)和排除(exclude)列表来确定用户具有哪些角色。

用户会被认为分配了角色,如果:
  1. 用户被:
    • 列在角色包含列表里,或者
    • 是列在角色包含列表里的组的成员。
  2. 用户没有被:
    • 列在角色排除列表里,或者
    • 是列在角色排除列表里的组的成员。

排除列表优先级高于包含列表。

用户和组的角色包含和排除也可以使用管理控制台和 jboss-cli.sh 工具来完成。

只有具有 SuperUser 或 Administrator 角色的用户才能执行这个配置。

10.8.9.2. 配置用户和角色的分配

包含或排除用户的角色可以通过管理控制台和 jboss-cli.sh 进行配置。本节只展示如何使用管理控制台来完成。
只有具有 SuperUser 或 Administrator 角色的用户才能执行这些配置。

在管理控制台里可通过下列步骤来配置用户和角色:
  1. 登陆到管理控制台。
  2. 点击『Administration』标签页。
  3. 展开左侧的『Access Control』并选择『Role Assignment』。
  4. 选择『USERS』标签页。
管理控制台里的用户角色管理的截屏

图 10.1. 管理控制台里的用户角色管理

过程 10.11. 为用户创建新的角色分配

  1. 登陆到管理控制台。
  2. 进入『Role Assignment』的『Users』标签页。
  3. 点击用户列表右上角的『Add』按钮。『Add User』对话框会出现。
    『Add User』对话框的截屏

    图 10.2. 『Add User』对话框

  4. 指定用户名,可选择输入区名。
  5. 选择是包含(include)还是排除(exclude)。
  6. 点击角色旁的复选框。你可以使用 Ctl 键(OSX 上的 Command 键)来选择多个选项。
  7. 点击『Save』按钮。
    保存成功后,『Add User』对话框将会关闭,用户列表将会更新以反映所作的修改。如果不成功则会显示 "Failed to save role assignment" 消息。

过程 10.12. 更新用户的角色分配

  1. 登陆到管理控制台。
  2. 进入『Role Assignment』的『Users』标签页。
  3. 从列表里选择用户。
  4. 点击『Edit』。『Selection』面板将进入编辑模式。
    『Selection』编辑视图的截屏

    图 10.3. 『Selection』面板的编辑视图

    在这里你可以添加和删除所分配或排除的角色。
    1. 要添加被分配的角色,从左侧的『Available roles』列表里进行选择并点击『Assigned roles』列表旁的右箭头。角色将从可用列表移至『Assigned roles』列表。
    2. 要删除被分配的角色,从右侧的『Assigned roles』列表里选择要删除的角色,并点击旁边的左箭头。角色将从『Assigned roles』列表移至『Available roles』列表。
    3. 要添加被排除的角色,从左侧的『Available roles』列表里进行选择并点击『Excluded roles』列表旁的右箭头。角色将从可用列表移至『Excluded roles』列表。
    4. 要删除被排除的角色,从右侧的『Excluded roles』列表里选择要删除的角色,并点击旁边的左箭头。角色将从『Excluded roles』列表移至『Available roles』列表。
  5. 点击『Save』按钮。
    成功后,编辑视图将会关闭,用户列表将会更新以反映所作的修改。如果不成功则会显示 "Failed to save role assignment" 消息。

过程 10.13. 删除用户的角色分配

  1. 登陆到管理控制台。
  2. 进入『Role Assignment』的『Users』标签页。
  3. 从列表里选择用户。
  4. 点『Remove』按钮。『Remove Role Assignment』确认框将出现。
  5. 点击『Confirm』按钮。
    成功后,用户将不会再出现在用户角色分配的列表里。

重要

从角色分配列表里删除用户并不会从系统删除这个用户,也不能保证没有角色被分配给这个用户。角色仍可能通过组成员资格分配给用户。

10.8.9.3. 用 jboss-cli.sh 配置用户角色分配

包含或排除用户的角色可以通过管理控制台和 jboss-cli.sh 进行配置。本节只展示如何使用 jboss-cli.sh 工具来完成。
映射用户/组到角色的配置位于 management API 里的 /core-service=management/access=authorization as role-mapping 元素。
只有具有 SuperUser 或 Administrator 角色的用户才能执行这些配置。

过程 10.14. 查看角色分配配置

  1. 使用 :read-children-names 操作来获取配置角色的完整列表:
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
    {
        "outcome" => "success",
        "result" => [
            "ADMINISTRATOR",
            "DEPLOYER",
            "MAINTAINER",
            "MONITOR",
            "OPERATOR",
            "SuperUser"
        ]
    }
    
  2. 使用指定 role-mapping 的 read-resource 操作来获取某个角色的完整细节:
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    [standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true)
    {
        "outcome" => "success",
        "result" => {
            "include-all" => false,
            "exclude" => undefined,
            "include" => {
                "user-theboss" => {
                    "name" => "theboss",
                    "realm" => undefined,
                    "type" => "USER"
                },
                "user-harold" => {
                    "name" => "harold",
                    "realm" => undefined,
                    "type" => "USER"
                },
                "group-SysOps" => {
                    "name" => "SysOps",
                    "realm" => undefined,
                    "type" => "GROUP"
                }
            }
        }
    }
    [standalone@localhost:9999 access=authorization]
    

过程 10.15. 添加新的角色

这个过程展示了如何添加角色的 role-mapping 条目。这必须在角色可以被配置前完成。
  • 使用 add 操作来添加新的角色配置。
    /core-service=management/access=authorization/role-mapping=ROLENAME:add
    ROLENAME 是新映射使用的角色的名称。
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR:add             
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    

过程 10.16. 添加包含在角色里的用户

这个过程展示了如何添加用户到角色的包含列表里。
如果角色的配置还未完成,那你必须先设置 role-mapping 条目。
  • 请使用 add 操作来添加用户到角色的包含列表里。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
    ROLENAME 是被配置的角色的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 user-USERNAME
    USERNAME 是添加到包含列表里的用户的名称。
     [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:add(name=max, type=USER)
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    

过程 10.17. 添加角色所排除的用户

这个过程展示了如何添加用户到角色的排除列表里。
如果角色的配置还未完成,那你必须先设置 role-mapping 条目。
  • 请使用 add 操作来添加用户到角色的排除列表里。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
    ROLENAME 是被配置的角色的名称。
    USERNAME 是添加到排除列表里的用户的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 user-USERNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:add(name=max, type=USER)
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    

过程 10.18. 删除用户的角色包含配置

这个过程展示了如何从角色映射里删除用户包含条目。
  • 请使用 remove 操作来删除这个条目。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    ROLENAME 是被配置的角色的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 user-USERNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:remove
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    
    从包含列表里删除用户并不会从系统删除这个用户,也不能保证角色不会被分配给这个用户。这个角色仍可能根据组成员资格分配给它。

过程 10.19. 删除用户的角色排除配置

这个过程展示了如何从角色映射里删除用户排除条目。
  • 请使用 remove 操作来删除这个条目。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    ROLENAME 是被配置的角色的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 user-USERNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:remove
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    
    从排除列表里删除用户并不会从系统删除这个用户,也不能保证角色被分配给这个用户。这个角色仍可能根据组成员资格被排除。

10.8.9.4. 关于角色和用户组

使用 mgmt-users.properties 文件或 LDAP 服务器验证的用户可以是用户组的成员。用户组是可以分配给一个或多个用户的任意标签。
你可以配置 RBAC 系统根据用户所在的用户组自动分配角色给用户。它也可以根据用户组成员资格来排除用户。
当使用 mgmt-users.properties 文件时,组信息保存在 mgmt-groups.properties 文件里。当使用 LDAP 时,组信息保存在 LDAP 服务器里并由负责 LDAP 服务器的人员来维护。

10.8.9.5. 配置组角色的分配

角色可以根据用户的用户组成员资格分配给用户。
角色包含或排除组可以通过管理控制台和 jboss-cli.sh 进行配置。本节只展示如何使用管理控制台来完成。
只有具有 SuperUser 或 Administrator 角色的用户才能执行这些配置。
在管理控制台里可通过下列步骤来配置组和角色:
  1. 登陆到管理控制台。
  2. 点击『Administration』标签页。
  3. 展开左侧的『Access Control』并选择『Role Assignment』。
  4. 选择『GROUPS』标签页。
管理控制台里的组角色管理的截屏

图 10.4. 管理控制台里的组角色管理

过程 10.20. 为组创建新的角色分配

  1. 登陆到管理控制台
  2. 进入『Role Assignment』的『GROUPS』标签页。
  3. 点击用户列表右上角的『Add』按钮。『Add Group』对话框会出现。
    『Add Group』对话框的截屏

    图 10.5. 『Add Group』对话框

  4. 指定组名,可选择输入区名。
  5. 选择是包含(include)还是排除(exclude)。
  6. 点击角色旁的复选框。你可以使用 Ctl 键(OSX 上的 Command 键)来选择多个选项。
  7. 点击『Save』按钮。
    保存成功后,『Add Group』对话框将会关闭,组列表将会更新以反映所作的修改。如果不成功则会显示 "Failed to save role assignment" 消息。

过程 10.21. 更新组的角色分配

  1. 登陆到管理控制台。
  2. 进入『Role Assignment』的『GROUPS』标签页。
  3. 从列表里选择组。
  4. 点击『Edit』。『Selection』面板将进入编辑模式。
    编辑模式的『Selection』视图的截屏

    图 10.6. 『Selection』视图编辑模式

    在这里你可以添加和删除组里分配或排除的角色:
    • 要添加被分配的角色,从左侧的『Available roles』列表里进行选择并点击『Assigned roles』列表旁的右箭头。角色将从可用列表移至『Assigned roles』列表。
    • 要删除被分配的角色,从右侧的『Assigned roles』列表里选择要删除的角色,并点击旁边的左箭头。角色将从『Assigned roles』列表移至『Available roles』列表。
    • 要添加被排除的角色,从左侧的『Available roles』列表里进行选择并点击『Excluded roles』列表旁的右箭头。角色将从可用列表移至『Excluded roles』列表。
    • 要删除被排除的角色,从右侧的『Excluded roles』列表里选择要删除的角色,并点击旁边的左箭头。角色将从『Excluded roles』列表移至『Available roles』列表。
  5. 点击『Save』按钮。
    成功后,编辑视图将会关闭,组列表将会更新以反映所作的修改。如果不成功则会显示 "Failed to save role assignment" 消息。

过程 10.22. 删除组的角色分配

  1. 登陆到管理控制台。
  2. 进入『Role Assignment』的『GROUPS』标签页。
  3. 从列表里选择组。
  4. 点『Remove』按钮。『Remove Role Assignment』确认框将出现。
  5. 点击『Confirm』按钮。
    成功后,组将不会再出现在用户角色分配的列表里。
    从角色分配列表里删除组并不会从系统删除这个用户组,也不能保证没有角色被分配给这个组。每个组成员仍可能被直接分配角色。

10.8.9.6. 用 jboss-cli.sh 配置组角色

角色包含或排除组可以通过管理控制台和 jboss-cli.sh 进行配置。本节只展示如何使用 jboss-cli.sh 工具来完成。
映射用户/组到角色的配置位于 management API 里的 /core-service=management/access=authorization as role-mapping 元素。
只有具有 SuperUser 或 Administrator 角色的用户才能执行这些配置。

过程 10.23. 查看组角色分配配置

  1. 使用 read-children-names 操作来获取配置角色的完整列表:
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
    {
        "outcome" => "success",
        "result" => [
            "ADMINISTRATOR",
            "DEPLOYER",
            "MAINTAINER",
            "MONITOR",
            "OPERATOR",
            "SuperUser"
        ]
    }
    
  2. 使用指定 role-mapping 的 read-resource 操作来获取某个角色的完整细节:
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    [standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true)
    {
        "outcome" => "success",
        "result" => {
            "include-all" => false,
            "exclude" => undefined,
            "include" => {
                "user-theboss" => {
                    "name" => "theboss",
                    "realm" => undefined,
                    "type" => "USER"
                },
                "user-harold" => {
                    "name" => "harold",
                    "realm" => undefined,
                    "type" => "USER"
                },
                "group-SysOps" => {
                    "name" => "SysOps",
                    "realm" => undefined,
                    "type" => "GROUP"
                }
            }
        }
    }
    [standalone@localhost:9999 access=authorization]
    

过程 10.24. 添加新的角色

这个过程展示了如何添加角色的 role-mapping 条目。这必须在角色可以被配置前完成。
  • 使用 add 操作来添加新的角色配置。
    /core-service=management/access=authorization/role-mapping=ROLENAME:add
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR:add             
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    

过程 10.25. 添加包含在角色里的组

这个过程展示了如何添加组到角色的包含列表里。
如果角色的配置还未完成,那你必须先设置 role-mapping 条目。
  • 请使用 add 操作来添加组到角色的包含列表里。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
    ROLENAME 是被配置的角色的名称。
    GROUPNAME 是添加到包含列表里的组的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 group-GROUPNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:add(name=investigators, type=GROUP)
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    

过程 10.26. 添加角色所排除的组

这个过程展示了如何添加组到角色的排除列表里。
如果角色的配置还未完成,那你必须先创建 role-mapping 条目。
  • 请使用 add 操作来添加组到角色的排除列表里。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
    ROLENAME 是被配置的角色的名称。
    GROUPNAME 是添加到包含列表里的组的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 group-GROUPNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:add(name=supervisors, type=USER)
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    

过程 10.27. 删除组的角色包含配置

这个过程展示了如何从角色映射里删除组包含条目。
  • 请使用 remove 操作来删除这个条目。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    ROLENAME 是被配置的角色的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 group-GROUPNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:remove
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    
    从包含列表里删除组并不会从系统删除这个组,也不能保证角色不会被分配给这个组。这个角色仍可能分配给组里的用户。

过程 10.28. 删除组的角色排除配置

这个过程展示了如何从角色映射里删除组排除条目。
  • 请使用 remove 操作来删除这个条目。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    ROLENAME 是被配置的角色的名称。
    ALIAS 是这个映射的唯一名称。红帽推荐你对别名使用命名规则,如 group-GROUPNAME
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:remove
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    
    从排除列表里删除组并不会从系统删除这个组,也不能保证角色被分配给这个组。这个角色仍可能根据组成员资格被排除。

10.8.9.7. 关于用 LDAP 进行授权和组加载

在 LDAP 目录里,有些条目用于用户帐号而有些条目用于组,并通过使用属性来进行交叉引用。有些属性是从用户帐号引用组条目,或者是组上的属性引用作为组成员的用户。在一些服务器上,这两种交叉引用的形式都存在。

用户使用简单的用户名通过服务器来验证也是很常见的,搜索组成员信息取决于使用的目录服务器。你可以使用简单名称来执行搜索,也可以用目录里的用户条目的标识名来执行。

用户连接服务器的验证步骤总是先发生的,一旦它已经决定用户成功验证,服务器将开始加载用户组。因为验证和授权步骤都使用到 LDAP 服务器的连接,安全区包含一个优化办法,也就是任何用于验证的连接都将被组加载步骤重用。如下面的配置步骤所展示的,你可以在授权部分定义角色来将用户的简单名称转换为标识名,这可能复制在验证步骤发生的搜索,所以,如果用户名到标识名的搜索已被执行,那么这个搜索的结果就可以被缓存和重用而无需再次进行搜索。
<authorization>
    <ldap connection="...">
       <username-to-dn> <!-- OPTIONAL -->
           <!-- Only one of the following. -->
           <username-is-dn />
           <username-filter base-dn="..." recursive="..." user-dn-attribute="..." attribute="..." />
           <advanced-filter base-dn="..." recursive="..." user-dn-attribute="..." filter="..." />
        </username-to-dn>
       <group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
           <!-- One of the following -->
           <group-to-principal base-dn="..." recursive="..." search-by="...">
               <membership-filter principal-attribute="..." />
           </group-to-principal>
           <principal-to-group group-attribute="..." />
       </group-search>
    </ldap>
</authorization>

重要

有些例子里的属性是用默认值设置的,在此出现的目的是为了说明而已。当服务器进行持久化时,这些包含默认值的属性将从配置里删除。
username-to-dn

如上所述,有时候你需要在授权配置里定义如何从被验证的用户的用户名映射到 LDAP 目录里条目的标识名。username-to-dn 元素是关于它的定义的,只有下列两者都为 true 才要求定义这个元素:
  • 验证步骤不是通过 LDAP 进行的。
  • 组搜索在搜索过程中使用标识名。

请注意,当你阅读下面的例子时,你会觉得其验证配置是重复的,确实是这样 - 如果你只使用 LDAP 进行验证,那这并非必需的,因为将在验证过程中获取标识名。
1:1 username-to-dn

这个是最基本的配置形式,用于指定远程用户输入的用户名实际上是标识名。
<username-to-dn>
   <username-is-dn />
</username-to-dn>

因为这是定义的 1:1 的映射,所以没有其他可能的配置。
username-filter

下一个选项和上面验证步骤描述的选项非常类似,它简单地按照提供的用户名进行搜索。
<username-to-dn>
    <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" />
</username-to-dn>

可以在这里设置的属性是:
  • base-dn: 开始搜索的上下文的标识名。
  • recursive:搜索是否将扩展到子上下文。默认值为 false
  • attribute:根据提供的用户名尝试和匹配的用户条目的属性。默认值为 uid
  • user-dn-attribute:为获得用户标识名而读取的属性。默认值为 dn
advanced-filter

这个最后的选项指定了高级过滤器,和验证部分一样,这是使用自定义过滤器来定位用户标识名的机会。
<username-to-dn>
    <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" />
</username-to-dn>

对应 username-filter 的属性的默认值都是一样的,这里不再列出。新的属性是:
  • filter:用于搜索用户条目的过滤器,用户名将在占位符 {0} 里替换。

重要

XML 格式必须保持有效,定义过滤器来确保特殊字符(如 &)的正确格式。例如,对于 & 字符是 &amp;
组搜索

如上面所描述的,在搜索组成员资格信息时你可以使用两种风格。第一种是用户条目包含引用用户所属组的属性。第二种风格是组包含引用用户条目的属性。

当可以选择风格时,红帽推荐引用所用组的用户条目的配置。这是因为用这个方法时组信息可以通过读取已知标识名来加载而无需执行任何搜索。另外一个方法则要求额外的搜索来确定引用用户的组。

在描述配置之前,这里有几个 LDIF 例子来进行解释。

例 10.20. Principal to Group - LDIF 示例。

这个例子展示了用户 TestUserOne,它是 GroupOne 的成员,而 GroupOne 也是 GroupFive 的成员。通过属性 memberOf 展示了组成员资格,它被设置为用户(或组)所属的组的标识名。

这里没有展示的是用户可能具有多个 memberOf 的属性集,每个都对应该用户所属的组。
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
distinguishedName: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
userPassword:: e1NTSEF9WFpURzhLVjc4WVZBQUJNbEI3Ym96UVAva0RTNlFNWUpLOTdTMUE9PQ==

dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: group
objectClass: uidObject
uid: GroupOne
distinguishedName: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org

dn: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: group
objectClass: uidObject
uid: GroupFive
distinguishedName: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org

例 10.21. Group to Principal - LDIF 示例

这个例子展示了相同的用户 TestUserOne,它是 GroupOne 的成员(反之也是 GroupFive 的成员)- 然而在这个例子里,它是一个用于交叉引用的组到用户的属性 uniqueMember

用于组成员资格交叉引用的属性可以重复,如果你查看 GroupFive,那里也有一个没有显示在这里的对其他用户 TestUserFive 的引用。
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
userPassword:: e1NTSEF9SjR0OTRDR1ltaHc1VVZQOEJvbXhUYjl1dkFVd1lQTmRLSEdzaWc9PQ==

dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group One
uid: GroupOne
uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org

dn: uid=GroupFive,ou=subgroups,ou=groups,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group Five
uid: GroupFive
uniqueMember: uid=TestUserFive,ou=users,dc=group-to-principal,dc=example,dc=org
uniqueMember: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
通用组搜索

通过上面例子里展示的两种方法,我们知道首先需要定义两者共用的属性。
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
    ...
</group-search>
  • group-name:这个属性用来指定用于作为用户所属组列表返回的组名的格式。这可以是组名的简单格式或者是组的标识名,如果标识名是必需的,那这个属性可以设置为 DISTINGUISHED_NAME。默认值是 SIMPLE
  • iterative:这个属性用来指定在确定用户所属的组之后是否应该根据组所属的组迭代地进行搜索。如果启用了迭代搜索,那么我们将继续搜索,直到到达不是成员的组或检测到循环。它的默认值为 false

循环的组成员并不是一个问题。我们保存了每次搜索的记录来防止已搜索过的组被再次搜索。

重要

为了迭代式搜索能正常进行,组条目需要和用户条目一致,也就是使用相同的方法来确定用户所属的组和确定组所属组。但对于组到组的成员关系,如果用于交叉引用的属性或者引用方向有改动,那这就无法实现了。
  • group-dn-attribute:组条目上的哪个属性是其标识名。默认为 dn
  • group-name-attribute:组条目上的哪个属性是其简单名。默认为 uid

例 10.22. Principal to Group 配置示例

基于上面的 LDIF 例子,下面是一个循环加载用户组的配置示例,用来进行交叉引用的属性是用户的 memberOf
<authorization>
    <ldap connection="LocalLdap">
        <username-to-dn>
            <username-filter base-dn="ou=users,dc=principal-to-group,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
            <principal-to-group group-attribute="memberOf" />
        </group-search>
    </ldap>
</authorization>

这个配置最重要的方面是已添加了带有单个属性的 principal-to-group 元素。
  • group-attribute

例 10.23. Group to Principal 配置示例

这个例子展示了一个对上面的 group to principal LDIF 例子的迭代搜索。
<authorization>
      <ldap connection="LocalLdap">
          <username-to-dn>
              <username-filter base-dn="ou=users,dc=group-to-principal,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
          </username-to-dn>
          <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
              <group-to-principal base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org" recursive="true" search-by="DISTINGUISHED_NAME">
                  <membership-filter principal-attribute="uniqueMember" />
              </group-to-principal>
          </group-search>
      </ldap>
  </authorization>

在这里添加了 group-to-principal 元素,这个元素用来定义引用用户条目的组搜索如何只执行,它将设置下列属性:
  • base-dn: 开始搜索的上下文的标识名。
  • recursive:是否搜索子上下文。默认为 false
  • search-by:在搜索里使用的角色名称的格式。有效值是 SIMPLEDISTINGUISHED_NAME。默认值为 DISTINGUISHED_NAME

group-to-principal 元素里有一个定义交叉引用的 membership-filter 元素。
  • principal-attribute:引用用户条目的组条目上的属性名称。默认值为 member

10.8.9.8. 关于带作用域的角色

带作用域的角色(Scoped Role)是用户定义的角色,它赋予标准角色中一个角色的权限,但只用于一个或多个指定的服务器组或主机。带作用域的角色允许按需要赋予管理用户限于某些服务器组或主机的权限。

带作用域的角色可以由具有 Administrator 或 SuperUser 角色的用户来创建。

它们是由 5 个特征定义的:
  1. 唯一的名字。
  2. 基于那些标准角色。
  3. 是否应用在服务器组或主机上。
  4. 所限的服务器组或主机的列表。
  5. 是否自动包括所有用户。默认为 false。

创建之后,带作用域的角色可以和标准角色一样分配给用户和组。

创建带作用域的角色并不意味着要定义新的权限。带作用域的角色只能用来在有限的作用域李应用现存角色的权限。例如,你可以根据限于单个服务器组的 Deployer 角色创建带作用域的角色。

角色只可以限于两个作用域,主机和服务器组。
作用域为主机的角色

作用域为主机的角色将它的权限限制到一个或多个主机。这意味着为相关的 /host=*/ 资源树提供了访问权限但其他主机所专有的资源是隐藏的。
作用域为服务器组的角色

作用域为服务器组的角色限制了该角色的权限到一个或多个服务器组。此外,角色权限将应用于和指定的服务器组相关联的配置集、套接字绑定组、服务器配置和服务器资源。和这个服务器组逻辑上不关联的资源的任何子资源对于用户来说都是不可见的。

作用域为主机和服务器组的角色都具有受管域配置的其他部分的 Monitor 角色的权限。

10.8.9.9. 创建带作用域的角色

带作用域的角色(Scoped Role)是用户定义的角色,它赋予标准角色中一个角色的权限,但只用于一个或多个指定的服务器组或主机。本节将展示如何创建带作用域的角色。

只有具有 SuperUser 或 Administrator 角色的用户才能执行这些配置。

在管理控制台里可通过下列步骤来配置带作用域的角色:
  1. 登录到管理控制台
  2. 点击 Administration 标签页
  3. 展开左侧的 Access Control 并选择 Role Assignment
  4. 选择 ROLES 标签页,然后选择里面的 Scoped Roles 标签页。
Scoped Role Configuration in the Management Console

图 10.7. 在管理控制台里配置带作用域的角色

管理控制台的 Scoped Roles fen 部分由两个主要区域组成,包含当前配置的带作用域的角色的表,以及显示表里当前别选择的角色细节。
下面的过程展示了如何配置带作用域的角色。

过程 10.29. 添加新的带作用域的角色

  1. 登录到管理控制台
  2. 导航至 Roles 标签页的 Scoped Roles 区域。
  3. 点击 Add 按钮。Add Scoped Role 对话框将会出现。
    Add Scoped Role Dialog

    图 10.8. Add Scoped Role 对话框

  4. 指定下列细节:
    • Name,新的带作用域的角色的唯一名称。
    • Base Role,这个角色的权限所基于的角色。
    • Type,这个角色是否将被限于主机或服务器组。
    • Scope,这个角色所限于的主机或服务器组列表。可以选择多重条目。
    • Include All,这个角色是否自动包含所有的用户。默认为 no。
  5. 点击 Save 按钮,对话框将关闭且新创建的角色将出现在表里。

过程 10.30. 编辑带作用域的角色

  1. 登录到管理控制台
  2. 导航至 Roles 标签页的 Scoped Roles 区域。
  3. 点击你要编辑的带作用域的角色。这个角色的细节将出现在表下面的 Selection 面板上。
    Role Selected

    图 10.9. 选择的角色

  4. 点击 Selection 面板上的 Edit 链接。Selection 面板将进入编辑模式。
    Selection Panel in Edit Mode

    图 10.10. 处于编辑模式的 Selection 面板

  5. 更新你要修改的细节并点击 Save 按钮。Selection 面板将回到之前的状态。Selection 面板和表都会显示最近更新的细节。

过程 10.31. 查看 Scoped Role 成员

  1. 登录到管理控制台
  2. 导航至 Roles 标签页的 Scoped Roles 区域。
  3. 点击表里你要查看成员的带作用域的角色,然后点击 Members 按钮。Members of role 对话框将出现。它将显示这个角色包含或排斥的用户和组。
    Role Membership Dialog

    图 10.11. Role Membership 对话框

  4. 当你已经完成查看这些信息后请点击 Done 按钮。

过程 10.32. 删除带作用域的角色

重要

如果用户或组被分配至某个角色,这个角色就不能被删除。你需要先删除角色分配。
  1. 登录到管理控制台
  2. 导航至 Roles 标签页的 Scoped Roles 区域。
  3. 选择表里要删除的带作用域的角色。
  4. 点击 Remove 按钮。Remove Scoped Role 对话框将出现。
  5. 点击 Confirm 按钮。对话框将关闭且角色会被删除。

10.8.10. 配置约束

10.8.10.1. 配置 Sensitivity 约束

每个敏感性约束(Sensitivity Constraint)都定义了被认为是 “敏感的”的资源的集合。敏感的资源通常是某种机密的内容,如密码,或者对服务器的操作有着重大影响的东西,如网络、JVM 配置或系统属性。访问控制系统本身也被视作敏感的资源。资源敏感性限制了哪些角色可以读、写或寻址专门的资源。

应用程序约束的配置位于管理 API 里的 /core-service=management/access=authorization/constraint=sensitivity-classification

在管理模型内部,每个 Sensitivity 约束都被标识为类别(classification)。这些类别被分组为类型(types)。有 39 种类别被分组成 13 个类型。

要配置 Sensitivity 约束,请使用 write-attribute 操作来设置 configured-requires-readconfigured-requires-writeconfigured-requires-addressable 属性。要使该类型的操作成为敏感的,请将其设置为 false。在默认情况下,它们不会被设置而使用 default-requires-readdefault-requires-writedefault-requires-addressable 的值。一旦配置的属性被设置,它将替代默认值。默认值不能被修改。

例 10.24. 使读取系统属性成为敏感性操作

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property
[domain@localhost:9999 classification=system-property] :write-attribute(name=configured-requires-read, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 classification=system-property] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configured-requires-addressable" => undefined,
        "configured-requires-read" => true,
        "configured-requires-write" => undefined,
        "default-requires-addressable" => false,
        "default-requires-read" => false,
        "default-requires-write" => true,
        "applies-to" => {
            "/host=master/system-property=*" => undefined,
            "/host=master/core-service=platform-mbean/type=runtime" => undefined,
            "/server-group=*/system-property=*" => undefined,
            "/host=master/server-config=*/system-property=*" => undefined,
            "/host=master" => undefined,
            "/system-property=*" => undefined,
            "/" => undefined
        }
    }
}
[domain@localhost:9999 classification=system-property]

表 10.3 “Sensitivity 约束配置结果” 总结了哪些角色能够执行哪些操作所取决的配置。

表 10.3. Sensitivity 约束配置结果

requires-read requires-write requires-addressable

true

读操作是敏感的。

只有 Auditor, Administrator 和 SuperUser 可以读。

写操作是敏感的。

只有 Administrator 和 SuperUser 可以写

寻址(Addressing)是敏感的。

只有 Auditor, Administrator 和 SuperUser 可以寻址。

false

读操作是非敏感的。

任何管理用户都可以读。

写操作是非敏感的。

只有 Maintainer, Administrator 和 SuperUser 可以写。如果这个约束是一个应用程序资源的话,Deployers 也可以写。

寻址(Addressing)是非敏感的。

任何管理用户都可以寻址。

10.8.10.2. 配置应用程序资源约束

每个应用程序资源约束都定义了一系列通常和应用程序及服务部署相关联的资源、属性和操作。当启用了应用程序资源约束时,具有 Deployer 角色的管理用户会被赋予访问资源的权限。

应用程序约束配置位于 /core-service=management/access=authorization/constraint=application-classification/ 里的管理模型。

在管理模型内部,每个应用程序资源约束都被标识为类别(classification)。这些类别被分组为类型(types)。有 14 种类别被分组成 8 个类型。每个类别都有一个 applies-to 元素,它是一个类别配置应用的资源路径模式的列表。

在默认情况下,唯一启用的应用程序资源类别是 core。Core 包含部署、部署重叠和部署操作。

要启用应用程序资源,请使用 write-attribute 操作来设置 configured-application attributetrue。要禁用应用程序资源,请设置这个属性为 false。在默认情况下,这些属性没被设置且使用了 default-application 属性的值。这个默认值不能被修改。

例 10.25. 启用 logger-profile 应用程序资源归类

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile
[domain@localhost:9999 classification=logging-profile] :write-attribute(name=configured-application, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 classification=logging-profile] :read-resource 
{
    "outcome" => "success",
    "result" => {
        "configured-application" => true,
        "default-application" => false,
        "applies-to" => {"/profile=*/subsystem=logging/logging-profile=*" => undefined}
    }
}
[domain@localhost:9999 classification=logging-profile]

重要

应用程序资源约束应用域所有匹配它的配置的资源。例如,只将 Deployer 用户权限赋予一个数据源资源而不是另外一个是不可能的。如果需要这种级别的分离,那么我们推荐在其他的服务器组里配置资源并为每个组创建不同作用域的 Deployer 角色。

10.8.10.3. 配置 Vault 表达式约束

在默认情况下,读和写 Vault 表达式是敏感操作。配置 Vault 表达式约束允许你设置这两个操作为非敏感的。修改这个约束允许更多的角色读和写 Vault 表达式。

Vault 表达式约束的配置位于 /core-service=management/access=authorization/constraint=vault-expression 上的管理模型里。

要配置 Vault 表达式,请使用 write-attribute 操作来设置 configured-requires-writeconfigured-requires-read 的属性为 truefalse。在默认情况下,它们不会被设置而使用 default-requires-readdefault-requires-write 的值。默认值不能被修改。

例 10.26. 使写入 Vault 表示成为非敏感操作

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=vault-expression
[domain@localhost:9999 constraint=vault-expression] :write-attribute(name=configured-requires-write, value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 constraint=vault-expression] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}
[domain@localhost:9999 constraint=vault-expression]

表 10.4 “Vault 表达式约束配置结果” 总结了哪些角色能够读取和写入 Vault 表达式所取决的配置。

表 10.4. Vault 表达式约束配置结果

requires-read requires-write

true

读操作是敏感的。

只有 Auditor, Administrator 和 SuperUser 可以读。

写操作是敏感的。

只有 Administrator 和 SuperUser 可以写。

false

读操作是不敏感的。

所有管理用户都可以读。

写操作是不敏感的。

Monitor, Administrator 和 SuperUser 都可以写。如果 Vault 表达式是一个应用程序资源的话,Deployers 也可以写。

10.8.11. 约束引用

10.8.11.1. 应用程序资源约束引用

类型:core

类别:deployment-overlay
  • 默认值:true
    PATH 属性 操作

    /deployment-overlay=*

    /deployment=*

    /

    upload-deployment-stream, full-replace-deployment, upload-deployment-url, upload-deployment-bytes

类型:datasources

类别:datasource
  • 默认值:false
    PATH 属性 操作

    /deployment=*/subdeployment=*/subsystem=datasources/data-source=*

    /subsystem=datasources/data-source=*

    /subsystem=datasources/data-source=ExampleDS

    /deployment=*/subsystem=datasources/data-source=*
Classification: jdbc-driver
  • 默认值:false
    PATH 属性 操作

    /subsystem=datasources/jdbc-driver=*
类别:xa-data-source
  • 默认值:false
    PATH 属性 操作

    /subsystem=datasources/xa-data-source=*

    /deployment=*/subsystem=datasources/xa-data-source=*

    /deployment=*/subdeployment=*/subsystem=datasources/xa-data-source=*

类型:logging

类别:logger
  • 默认值:false
    PATH 属性 操作

    /subsystem=logging/logger=*

    /subsystem=logging/logging-profile=*/logger=*
类别:logging-profile
  • 默认值:false
    PATH 属性 操作

    /subsystem=logging/logging-profile=*

类型:mail

类别:mail-session
  • 默认值:false
    PATH 属性 操作

    /subsystem=mail/mail-session=*

类型:naming

类别:binding
  • 默认值:false
    PATH 属性 操作

    /subsystem=naming/binding=*

类型:resource-adapters

类别:resource-adapters
  • 默认值:false
    PATH 属性 操作

    /subsystem=resource-adapters/resource-adapter=*

类型:security

类别:security-domain
  • 默认值:false
    PATH 属性 操作

    /subsystem=security/security-domain=*

10.8.11.2.  安全约束引用

类型:core

类别:access-control
  • requires-addressable: true
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /core-service=management/access=authorization

    /subsystem=jmx

    non-core-mbean-sensitivity
类别:credential
  • requires-addressable: false
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /subsystem=mail/mail-session=*/server=pop3

    username , password

    /subsystem=mail/mail-session=*/server=imap

    username, password

    /subsystem=datasources/xa-data-source=*

    user-name, recovery-username, password, recovery-password

    /subsystem=mail/mail-session=*/custom=*

    username, password

    /subsystem=datasources/data-source=*"

    user-name, password

    /subsystem=remoting/remote-outbound-connection=*"

    username

    /subsystem=mail/mail-session=*/server=smtp

    username , password

    /subsystem=web/connector=*/configuration=ssl

    key-alias, password

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*"

    recovery-username, recovery-password
类别:domain-controller
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作
类别:domain-names
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作
类别:extensions
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /extension=*
类别:jvm
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=platform-mbean/type=runtime

    input-arguments, boot-class-path, class-path, boot-class-path-supported, library-path
类别:management-interfaces
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=management/management-interface=native-interface

    /core-service=management/management-interface=http-interface
类别:module-loading
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=module-loading
类别:patching
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=patching/addon=*

    /core-service=patching/layer=*"

    /core-service=patching
类别:read-whole-config
  • requires-addressable: false
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /

    read-config-as-xml
类别:security-domain
  • requires-addressable: true
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /subsystem=security/security-domain=*
类别:security-domain-ref
  • requires-addressable: true
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /subsystem=datasources/xa-data-source=*

    security-domain

    /subsystem=datasources/data-source=*

    security-domain

    /subsystem=ejb3

    default-security-domain

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*

    security-domain, recovery-security-domain, security-application, security-domain-and-application
类别:security-realm
  • requires-addressable: true
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /core-service=management/security-realm=*
类别:security-realm-ref
  • requires-addressable: true
  • requires-read: true
  • requires-write: true
    PATH 属性 操作

    /subsystem=remoting/connector=*

    security-realm

    /core-service=management/management-interface=native-interface

    security-realm

    /core-service=management/management-interface=http-interface

    security-realm

    /subsystem=remoting/remote-outbound-connection=*

    security-realm
类别:security-vault
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=vault
类别:service-container
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=service-container
类别:snapshots
  • requires-addressable: false
  • requires-read: false
  • requires-write: false
    PATH 属性 操作

    /

    take-snapshot, list-snapshots, delete-snapshot
类别:socket-binding-ref
  • requires-addressable: false
  • requires-read: false
  • requires-write: false
    PATH 属性 操作

    /subsystem=mail/mail-session=*/server=pop3

    outbound-socket-binding-ref

    /subsystem=mail/mail-session=*/server=imap

    outbound-socket-binding-ref

    /subsystem=remoting/connector=*

    socket-binding

    /subsystem=web/connector=*

    socket-binding

    /subsystem=remoting/local-outbound-connection=*

    outbound-socket-binding-ref

    /socket-binding-group=*/local-destination-outbound-socket-binding=*

    socket-binding-ref

    /subsystem=remoting/remote-outbound-connection=*

    outbound-socket-binding-ref

    /subsystem=mail/mail-session=*/server=smtp

    outbound-socket-binding-ref

    /subsystem=transactions

    process-id-socket-binding, status-socket-binding, socket-binding
类别:socket-config
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /interface=*

    resolve-internet-address

    /core-service=management/management-interface=native-interface

    port, interface, socket-binding

    /socket-binding-group=*

    /core-service=management/management-interface=http-interface

    port, secure-port, interface, secure-socket-binding, socket-binding

    /

    resolve-internet-address

    /subsystem=transactions

    process-id-socket-max-ports
类别:system-property
  • requires-addressable: false
  • requires-read: false
  • requires-write: true
    PATH 属性 操作

    /core-service=platform-mbean/type=runtime

    system-properties

    /system-property=*

    /

    resolve-expression